Re: gdb stack trace problems

[Mark Kettenis <mark.kettenis@xs4all.nl>]

   Date: Mon, 18 Apr 2005 09:57:21 -0400
   From: Daniel Jacobowitz <drow@false.org>

   > Program received signal SIGSEGV, Segmentation fault.
   > [Switching to thread 2316.0xf8c]
   > 0x0040131d in crashIfZero (num=2) at gdbtest.c:17
   > 17                      *data=911;
   > (gdb) thr 1
   > [Switching to thread 1 (thread 2316.0xf10)]#0  0x7c91eb94 in 
   > ntdll!LdrAccessResource () from ntdll.dll
   > (gdb) bt
   > #0  0x7c91eb94 in ntdll!LdrAccessResource () from ntdll.dll
   > #1  0x7c91d85c in ntdll!ZwDelayExecution () from ntdll.dll
   > #2  0x7c8023ed in SleepEx () from /vol/c/WINDOWS/system32/kernel32.dll
   > #3  0x00000000 in ?? () from

   OK, here's a concrete problem.  GDB 6.x has a (usually) more reliable
   prologue analyzer for x86, compared to GDB 5.3.  However, the old one
   got lucky with SleepEx and the new one doesn't.  I'd ask you to post
   disassembly of the function except I'm not sure how wise that is with a
   Microsoft DLL...

   Mark, you did the work on the i386 prologue analyzer.  Any chance you
   could take a look at this?

Sure if someone can provide me with the dissassembly in AT&T syntax
for that function, or even better some assembler code that exhibits
the problem.  No promises though that I'll fix this.  Last time I
looked at some windows disassembler it looked like it was hand
optimized in such a way that the entire function needed to be analyzed
to do something useful; something that doesn't quite fit in the way we
do things in GDB.

Mark