Nope, still doesn't appear to work. Rein, you see the same?
Chris
On Sunday 30 November 2003 11:08 am, Eric Pouech wrote:
Chris Morgan wrote:
Still isn't working with build from todays cvs. Is this patch in there?
it seems that AJ applied it after your mail had been sent A+
On Sun, 30 Nov 2003 12:36:25 -0500, you wrote:
Nope, still doesn't appear to work. Rein, you see the same?
Chris
On Sunday 30 November 2003 11:08 am, Eric Pouech wrote:
Chris Morgan wrote:
Still isn't working with build from todays cvs. Is this patch in there?
it seems that AJ applied it after your mail had been sent A+
Still the same here. It can be a bug in Debian Sid of course, and the with the flow of updates stopped ...
Rein.
On Sun, 2003-11-30 at 19:51, Rein Klazes wrote:
Still the same here. It can be a bug in Debian Sid of course, and the with the flow of updates stopped ...
FWIW I see the same problem here now on RH9
Mike Hearn wrote:
On Sun, 2003-11-30 at 19:51, Rein Klazes wrote:
Still the same here. It can be a bug in Debian Sid of course, and the with the flow of updates stopped ...
FWIW I see the same problem here now on RH9
I'm just trying to figure out what could be different on your side from mine. Are you all using nptl support ? A+
On Sun, 2003-11-30 at 21:01, Eric Pouech wrote:
I'm just trying to figure out what could be different on your side from mine. Are you all using nptl support ?
Well, I am using NPTL yes. Some time next week I can give you access to my machine, if you feel like some hands on debugging.
thanks -mike
On Sun, 30 Nov 2003 22:01:22 +0100, you wrote:
Mike Hearn wrote:
On Sun, 2003-11-30 at 19:51, Rein Klazes wrote:
Still the same here. It can be a bug in Debian Sid of course, and the with the flow of updates stopped ...
FWIW I see the same problem here now on RH9
I'm just trying to figure out what could be different on your side from mine. Are you all using nptl support ?
I am not. glibc 2.3.2 on not-patched kernel 2.4.22.
Rein.
On Monday 01 December 2003 12:31 am, Rein Klazes wrote:
On Sun, 30 Nov 2003 22:01:22 +0100, you wrote:
Mike Hearn wrote:
On Sun, 2003-11-30 at 19:51, Rein Klazes wrote:
Still the same here. It can be a bug in Debian Sid of course, and the with the flow of updates stopped ...
FWIW I see the same problem here now on RH9
I'm just trying to figure out what could be different on your side from mine. Are you all using nptl support ?
I am not. glibc 2.3.2 on not-patched kernel 2.4.22.
Rein.
poking around I find that the for loop in DEBUG_RegisterStabsDebugInfo (in programs/winedbg/msc.c) never finds the .stab or .stabstr sections... not sure if they are really there or not. For example, for ntdll, it finds only .data and .text.... Not sure what's really wrong here; for now, it's my bedtime :P
On Tuesday 02 December 2003 01:02 am, Gregory M. Turner wrote:
On Monday 01 December 2003 12:31 am, Rein Klazes wrote:
On Sun, 30 Nov 2003 22:01:22 +0100, you wrote:
Mike Hearn wrote:
On Sun, 2003-11-30 at 19:51, Rein Klazes wrote:
Still the same here. It can be a bug in Debian Sid of course, and the with the flow of updates stopped ...
FWIW I see the same problem here now on RH9
I'm just trying to figure out what could be different on your side from mine. Are you all using nptl support ?
I am not. glibc 2.3.2 on not-patched kernel 2.4.22.
Rein.
poking around I find that the for loop in DEBUG_RegisterStabsDebugInfo (in programs/winedbg/msc.c) never finds the .stab or .stabstr sections... not sure if they are really there or not. For example, for ntdll, it finds only .data and .text.... Not sure what's really wrong here; for now, it's my bedtime :P
One more tidbit: readelf clearly shows the .stab and .stabstr sections are there... any thoughts on this?
poking around I find that the for loop in DEBUG_RegisterStabsDebugInfo (in programs/winedbg/msc.c) never finds the .stab or .stabstr sections... not sure if they are really there or not. For example, for ntdll, it finds only .data and .text.... Not sure what's really wrong here; for now, it's my bedtime :P
do you mean the one in msc.c or the one in stabs.c ? the one in msc.c is only used to support PE modules when compiled under mingw. The one you're interested in is in stabs.c (it's for ELF modules). A+
On Wednesday 03 December 2003 12:57 pm, Eric Pouech wrote:
poking around I find that the for loop in DEBUG_RegisterStabsDebugInfo (in programs/winedbg/msc.c) never finds the .stab or .stabstr sections... not sure if they are really there or not. For example, for ntdll, it finds only .data and .text.... Not sure what's really wrong here; for now, it's my bedtime :P
do you mean the one in msc.c or the one in stabs.c ? the one in msc.c is only used to support PE modules when compiled under mingw. The one you're interested in is in stabs.c (it's for ELF modules). A+
aha! Well, I'm afraid I definitely was messing with msc.c (what you say makes perfect sense, I had wondered why stabs stuff was there (I guess for mingw as you mention)). Armed with this info I'll take another look. For presumably transient reasons which I don't quite fathom, my gdb won't debug wine right now either... so I'm simply using creative TRACE's for now... yuck.
I had followed ctags from DEBUG_LoadModule32 in module.c into msc.c... I guess, instead, I should be looking at the path:
winedbg.c:DEBUG_HandleDebugEvent -> stabs.c:DEBUG_ReadExecutableDbgInfo
?
Thanks for your help.
Gregory M. Turner wrote:
On Wednesday 03 December 2003 12:57 pm, Eric Pouech wrote:
poking around I find that the for loop in DEBUG_RegisterStabsDebugInfo (in programs/winedbg/msc.c) never finds the .stab or .stabstr sections... not sure if they are really there or not. For example, for ntdll, it finds only .data and .text.... Not sure what's really wrong here; for now, it's my bedtime :P
do you mean the one in msc.c or the one in stabs.c ? the one in msc.c is only used to support PE modules when compiled under mingw. The one you're interested in is in stabs.c (it's for ELF modules). A+
aha! Well, I'm afraid I definitely was messing with msc.c (what you say makes perfect sense, I had wondered why stabs stuff was there (I guess for mingw as you mention)). Armed with this info I'll take another look. For presumably transient reasons which I don't quite fathom, my gdb won't debug wine right now either... so I'm simply using creative TRACE's for now... yuck.
I had followed ctags from DEBUG_LoadModule32 in module.c into msc.c... I guess, instead, I should be looking at the path:
winedbg.c:DEBUG_HandleDebugEvent -> stabs.c:DEBUG_ReadExecutableDbgInfo
?
Thanks for your help.
you should be looking at DEBUG_ProcessElfObject (DEBUG_ReadExecutableDbgInfo is only called for the executable itself, not for every loaded shared lib). A+
-
Chris Morgan -
Eric Pouech -
Gregory M. Turner -
Mike Hearn -
Rein Klazes