On Friday 05 December 2003 04:15 pm, Chris Morgan wrote:
I can see about making this change as I did it once before for the jack audio driver.
Can someone fix the debug symbols issue? I've got a patch for the jack driver that I'm having trouble debugging without it :-P
I think this may be going slow since the "right people" are not experiencing this problem, and are therefore unable to try to fix it.
I'm still looking into it, since I have at least a minimal amount of experience toying with winedbg and my wine exhibits the problem, but of course I am a bit out of my depth with some of this stuff, and the fact that gdb doesn't work for me isn't making it any easier.
Here's the latest I know, after spending very little time, so far, looking into it: First, the routine which Eric suggested I start my research with (DEBUG_ProcessElfObject), is not called, except for the wine executable itself. That is, DEBUG_ProcessElfObject is never called for any .dll.so files whatsoever. Secondly, in the case of the wine executable (by this I mean the "wine" file) DEBUG_ProcessElfObject fails to find symbols, as DEBUG_ProcessElfFile returns DIL_NOINFO (I'm not sure why, yet).
Is it possible that the latter problem causes the former? That is, if "wine" is not found to contain debug symbols, will winedbg stop trying to load symbols for native wine libraries?
Barring that, I ought to try to determine why it never runs... but I'm a bit confused as to how winedbg ever ends up at DEBUG_ProcessElfObject in the case of a library. Could someone with a working winedbg show me a stack trace at the point where winedbg calls DEBUG_ProcessElfObject for a .dll.so library? This might help me to figure out where my wine diverges from the expected execution path.
Wish me luck. Depending on the complexity of the root cause I may just not have what it takes, but I'm happy to patiently plod forward until I hit a brick wall, as this situation is making it difficult for me to work, as well.