debugging problems (was Re: Suggestion - don't require sane and artsc)

Eric Pouech pouech-eric at wanadoo.fr
Sat Dec 6 00:15:37 CST 2003


> 
> 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?
not really, in fact not reading .so file is linked to being able (or 
not) to read the .dynamic section of the ELF header

> 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.
Basically, the way it goes is:
	1/ load the main exec (from its pathname)
	2/ get the loaded ELF information from file image
	3/ get address of a specific function (in ELF loading) which gets 
called each time a .so shared lib is loaded/unloaded (in debuggee 
address space)
	4/ set a breakpoint on this function (in debuggee address space)
	5/ set a winedbg specific handler for this breakpoint which will load 
debug info for any new share lib when the bp is hit (we don't handle yet 
shared lib unloading).
It seems, from what you describe, that step 1/ or 2/ is failing. Could 
you send me your wine-{kp}thread file so that I get a small glance at this.

> 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.
> 

A+
-- 
Eric Pouech




More information about the wine-devel mailing list