But why this should go unconditionally, without a dedicated debug channel (like, e. g., pid)? Or do you think those should be removed as well and all the possible context fields should just be there?
On 2/27/23 13:17, Zebediah Figura (@zfigura) wrote:
I haven't taken more than one look at the log output produced by this, so I can't say much for sure, but I'm inclined to agree that this is desirable, for pretty much the reasons Rémi gave. There are less parts of Wine that need this kind of disambiguation than that don't, but it doesn't seem too in-the-way either.
Even where the function name is unambiguous, I think there's a benefit in terms of reducing the need to ask questions like "is CreateFileMapping() in file.c or memory.c?" [Answer: neither, it's in sync.c.]
Thoughts:
Should we include the DLL name in the trace as well? I can see situations where that'd help (quartz, mfplat), but also it takes up space, and will usually be redundant with the channel...
Is there much of a point in including the line number? I doubt it, the file and function name is probably enough and from there you can easily browse to a trace. On the other hand, this *would* allow you to have multiple identical messages in the same function, which can be especially handy if you want to copy/paste a bunch of traces while debugging...
In response to Eric's comment:
I don't like the approach of solving a local issue by moving it at global scope. And increasing verbosity of logs for DLLs that are already very verbose will make things worse for these.
But this isn't a "local issue" exactly. It's a problem that occurs in multiple places. I've run into this in quartz. In some sense the only reason it's *not* more widespread is that we put namespace prefixes on things defensively.
Furthermore:
if context is important, why don't you include the DLL name in the trace?Like Rémi already said, that makes names unnecessarily long.
change to ntdll will break binary compatibility (eg some .so exec will no longer work)__wine_* APIs are internal and shouldn't be depended on anyway. This isn't the first time we've changed them.
IMO we'd be better off by:
increasing verbosity on a DLL and/or file approach this can be done without changing ntdll interface, by just replacing function parameter by a locally generated string including function + the context needed this could even go a step further as the printed context could be what the DLL/file is interested in (and could be different from filename+lineno...)This would make wine dlls inconsistent wrt how they print trace messages, and would also add more work for anyone who wants to take advantage of this. I don't think that's an improvement.