(Having just been caught by this again !!)
It would be nice if in the distributions we dynamically detected libartsc and libsane rather than requiring them. When someone is installing on a small computer they will tend to exclude irrelevant packages like scanner and sound software when they don't have a scanner or speakers.
(This paricularly relates to the RedHat 8.0 rpms)
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
Chris
On Fri, 5 Dec 2003 14:05:13 -0800 Bill Medland billmedland@mercuryspeed.com wrote:
(Having just been caught by this again !!)
It would be nice if in the distributions we dynamically detected libartsc and libsane rather than requiring them. When someone is installing on a small computer they will tend to exclude irrelevant packages like scanner and sound software when they don't have a scanner or speakers.
(This paricularly relates to the RedHat 8.0 rpms)
-- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed
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.
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+
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....
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+
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 AAAA dil = DIL_ERROR trace:debug:DEBUG_ProcessElfObject BBBB dil = DIL_ERROR trace:debug:DEBUG_ProcessElfObject CCCC dil = DIL_ERROR trace:debug:DEBUG_ProcessElfObject DDDD dil = DIL_ERROR trace:debug:DEBUG_ProcessElfFile Processing elf file 'wine' trace:debug:DEBUG_ProcessElfObject EEEE dil = DIL_ERROR trace:debug:DEBUG_ProcessElfObject FFFF 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 GGGG dil = DIL_LOADED trace:debug:DEBUG_ProcessElfObject HHHH dil = DIL_LOADED trace:debug:DEBUG_ProcessElfObject IIII dil = DIL_LOADED trace:debug:DEBUG_ProcessElfObject JJJJ dil = DIL_LOADED trace:debug:DEBUG_ReportDIL Loaded debug information from ELF 'wine' ((nil)) trace:debug:DEBUG_ProcessElfObject KKKK dil = DIL_LOADED trace:debug:DEBUG_ReadExecutableDbgInfo JJJJJJJJJJJJJJJ1111
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 "."
"Gregory M. Turner" gmturner007@ameritech.net 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?
On Wednesday 10 December 2003 04:30 pm, Alexandre Julliard wrote:
"Gregory M. Turner" gmturner007@ameritech.net 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....
Le ven 05/12/2003 à 17:05, Bill Medland a écrit :
(Having just been caught by this again !!)
It would be nice if in the distributions we dynamically detected libartsc and libsane rather than requiring them. When someone is installing on a small computer they will tend to exclude irrelevant packages like scanner and sound software when they don't have a scanner or speakers.
Sorry, that's the fault of the dependancy creator in the RPM version shipped with RH8. The RH9 rpms I do don't have those dependancies.
In fact, here's the output of rpm -q --requires -p wine-20031118-1rh9winehq.athlon.rpm: rpm shadow-utils /bin/sh /bin/sh /bin/sh /bin/sh rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 /bin/sh
Nothing out of the ordinary even for a small RH9 install...
(Can't do the same output for an RH8 rpm right now)
Take note that I basically use the same spec file for all RH versions (depending on the release, there's sometimes a patch for a specific issue with one or the other RH versions).
Vincent
-
Alexandre Julliard -
Bill Medland -
Chris Morgan -
Eric Pouech -
Gregory M. Turner -
Vincent Béron