Message-Id: <5.0.2.1.2.20030109143051.02a29ba8@ics.u-strasbg.fr>
X-Sender: muller AT ics DOT u-strasbg DOT fr
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 09 Jan 2003 14:42:38 +0100
To: djgpp-workers AT delorie DOT com
From: Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
Subject: Re: stubify
In-Reply-To: <200301091222.NAA19114@lws256.lu.erisoft.se>
References: <3E183620 DOT EDBE0071 AT phekda DOT freeserve DOT co DOT uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

At 13:22 09/01/2003, Martin Stromberg wrote:
>> 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()?


If you really want to check this kind oof stuff you should place a 
breakpoint at the exact location of the start of _lseek function.

If you set a breakpoint at _lseek, GDB will place this breakpoint after 
function prologue:
  this prologue usually contains something like
   push $ebp
   movl  $esp, $ebp
but if some registers are saved like in 'pushl $ebx'
that instruction is also considered as being part of the function prologue...
when I tested your file I obtained 3 registers pushed on stack before the 
location of the breakpoint.

Use 
'disas lseek' ( just shows a jmp __lseek)
but then 'disas __lseek' will show you the startup pushes that are 
considered part of function prologue.

If you want to see the args of a function, they are most of the time 
at $ebp + 8
(unless the compiler did not generate a stackframe entry code...)

Hoping this helps.