Re: gdb stack trace problems

[Roland Schwingel <roland.schwingel@onevision.de>]

Hi Mark, Daniel and list....

Mark Kettenis wrote on 18.04.2005 19:10:57:
 >    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.
Here is the disassembly of one function (func1) that cannot be shown 
correctly
from within gdb 6.3.50 in att flavor:
(gdb) disas func1
Dump of assembler code for function func1:
0x004013ca <func1+0>:   push   %ebp
0x004013cb <func1+1>:   mov    %esp,%ebp
0x004013cd <func1+3>:   sub    $0x8,%esp
0x004013d0 <func1+6>:   movl   $0x64,(%esp)
0x004013d7 <func1+13>:  call   0x401830 <Sleep@4>
0x004013dc <func1+18>:  sub    $0x4,%esp
0x004013df <func1+21>:  mov    0x8(%ebp),%eax
0x004013e2 <func1+24>:  mov    %eax,(%esp)
0x004013e5 <func1+27>:  call   0x4012eb <crashIfZero>
0x004013ea <func1+32>:  mov    0x8(%ebp),%eax
0x004013ed <func1+35>:  mov    %eax,(%esp)
0x004013f0 <func1+38>:  call   0x40139d <func2>
0x004013f5 <func1+43>:  leave 
0x004013f6 <func1+44>:  ret   
End of assembler dump.

I hope this is what you requested. I will aid in tracking this down,
wherever I can. As you see from the assembly Sleep() is
called not SleepEx() as shown in the gdb 6.3.50 stack
trace. In gdb 5.3 stack trace Sleep() is correctly shown if you
look at my posting from yesterday

Roland