Mail Archives: djgpp-workers/2003/01/09/07:22:29
> ams AT ludd DOT luth DOT se wrote:
> [snip]
> > 3. Meanwhile I discovered gdb's command "x/12wx $esp" doesn't seem to
> > work. I see some values but it sure doesn't look what I expect is on
> > the stack. (E. g. after calling lseek(3, 526, 0), I'd expect to see 0,
> > 526, 3 and <return EIP> on the stack.) I'm using gdb 5.1.1.
>
> Does it work with 5.2.1 or 5.3?
Checked with 5.3: yes. Mostly. However note that it's a different OS
(now some NT citrix weirdo, then W98).
> The call to lseek goes through a stub to get to __lseek, but that's a jmp not
> a call, so I guess it makes no difference to the stack.
That's my thought to. But using this program:
#include <unistd.h>
int f(int a, int b, int c)
{
a = b;
b = c;
c = a;
return 77;
}
int main(void)
{
f(1, 2, 3);
lseek(3, 2, 1);
return 0;
}
setting breakpoints on f() and lseek() I see
Breakpoint 1, f (a=1, b=586448, c=583968) at d1.c:11
11 }
(gdb) x/16wx $esp
0x8e8b8: 0x0008e8e0 0x00001604 0x00000001 0x00000002
0x8e8c8: 0x00000003 0x00000001 0x00000000 0x002a3484
0x8e8d8: 0x0008f2d0 0x0008f2d0 0x0008e910 0x00002eeb
0x8e8e8: 0x00000001 0x0008f2d0 0x0008e920 0x00000000
(gdb) c
Continuing.
Breakpoint 2, 0x00006f74 in __lseek ()
(gdb) x/16wx $esp
0x8e8b4: 0x0000027d 0x0008e8e0 0x00001612 0x00000003
0x8e8c4: 0x00000002 0x00000001 0x00000001 0x00000000
0x8e8d4: 0x002a3484 0x0008f2d0 0x0008f2d0 0x0008e910
0x8e8e4: 0x00002eeb 0x00000001 0x0008f2d0 0x0008e920
Looking at the first three values: 0x00001604 and 0x00001612 must be
the return addresses. 0x0008e8e0 is (probably) ebp. But what is that
0x0000027d that snuck in in the call to lseek()?
(This might have been what I saw with gdb 5.1.1 as well but as I
didn't write a simple test case I didn't recognise the numbers
easily.)
Right,
MartinS
- Raw text -