Re: debugging problems (was Re: Suggestion - don't require sane and artsc)
On Wednesday 10 December 2003 04:30 pm, Alexandre Julliard wrote:
> "Gregory M. Turner" <[EMAIL PROTECTED]> writes:
> > actually, AFAICS it's just looking at "wine"... where is a good place to
> > verify this (with a trace)? Perhaps this is the whole problem? I am not
> > mentally up-to-date on the latest with wine-{k,p}thread, the wrapper,
> > etc... maybe it's time to read up.
>
> Does it make a difference if you set WINELOADER to point to your wine
> binary?
*embarrasment emoticon* yep. like a charm
--
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
Re: debugging problems (was Re: Suggestion - don't require sane and artsc)
"Gregory M. Turner" <[EMAIL PROTECTED]> writes:
> actually, AFAICS it's just looking at "wine"... where is a good place to
> verify this (with a trace)? Perhaps this is the whole problem? I am not
> mentally up-to-date on the latest with wine-{k,p}thread, the wrapper, etc...
> maybe it's time to read up.
Does it make a difference if you set WINELOADER to point to your wine
binary?
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: debugging problems (was Re: Suggestion - don't require sane and artsc)
On Wednesday 10 December 2003 01:52 pm, Eric Pouech wrote:
> > 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?)
>
> yup
> 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?
>
> well, I suspect we could also lookup in the wrong file. Could you check
> that the name of the main ELF module we load in the debugger is actually
> the (full path) to the wine-(p|k)thread executable.
> A+
actually, AFAICS it's just looking at "wine"... where is a good place to
verify this (with a trace)? Perhaps this is the whole problem? I am not
mentally up-to-date on the latest with wine-{k,p}thread, the wrapper, etc...
maybe it's time to read up.
Here is one (partially homebrew) trace which may or may not already answer
this question for you (my wine prefix is '/opt/wine'):
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfFile Processing elf file 'wine'
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/bin/wrappers/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/local/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/opt/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file
'/usr/i686-pc-linux-gnu/gcc-bin/3.3/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/opt/ati/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/X11R6/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file
'/opt/sun-j2sdk-1.4.1/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file
'/opt/sun-j2sdk-1.4.1/jre/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/qt/3/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/kde/3.1/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/qt/2/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/opt/wine/bin/wine'
trace:debug:DEBUG_ProcessElfObject dil = DIL_LOADED
trace:debug:DEBUG_ProcessElfObject dil = DIL_LOADED
trace:debug:DEBUG_ProcessElfObject dil = DIL_LOADED
trace:debug:DEBUG_ProcessElfObject dil = DIL_LOADED
trace:debug:DEBUG_ReportDIL Loaded debug information from ELF 'wine' ((nil))
trace:debug:DEBUG_ProcessElfObject dil = DIL_LOADED
trace:debug:DEBUG_ReadExecutableDbgInfo JJJ
Note that I have managed to get it to load symbols for wine itself --
apparently the problem is that I was running wine with my cwd in root of the
build tree, although I don't understand that completely, as my $PATH does not
include "."
--
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
Re: debugging problems (was Re: Suggestion - don't require sane and artsc)
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?) yup 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? well, I suspect we could also lookup in the wrong file. Could you check that the name of the main ELF module we load in the debugger is actually the (full path) to the wine-(p|k)thread executable. A+ -- Eric Pouech
Re: debugging problems (was Re: Suggestion - don't require sane and artsc)
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
Re: debugging problems (was Re: Suggestion - don't require sane and artsc)
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
debugging problems (was Re: Suggestion - don't require sane and artsc)
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. -- 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
