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

[Gregory M. Turner]

On Saturday 06 December 2003 12:15 am, Eric Pouech wrote:
> not really, in fact not reading .so file is linked to being able (or
> not) to read the .dynamic section of the ELF header

Indeed.  Looking at the loop in DEBUG_ReadExecutableDbgInfo, the values of 
dyn.d_tag it iterates through look nothing like the output of "readelf -d 
wine" (they should, right?)  The numbers it shows me (after adding a trace) 
don't even map to the DT_ constants I see in elf.h at all... (again, I 
presume that they should?  fwiw, readelf -d does show a DEBUG tag)  I guess, 
this probably means there is a problem in DEBUG_ProcessElfFile finding the 
right address for the .dynamic section?

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

I think I see what you are talking about -- this is supposed to be set up in 
DEBUG_ReadExecutableDbgInfo, right?  But where it says "if (dyn.d_tag == 
DT_NULL) goto leave;" my wine does indeed goto leave.  My guess is, it's just 
fishing through some pseudo-arbitrary ram until it finds a zero....  

-- 
gmt

"It is to be the assent and ratification of the several States,
derived from the supreme authority in each State, the authority
of the people themselves.  The act, therefore, establishing the
Constitution, will not be a NATIONAL, but a FEDERAL act." --James
Madison, Federalist No. 39