X-Sybari-Trust: aedf9391 1864f774 d5511081 00000138 From: Martin Stromberg Message-Id: <200301091222.NAA19114@lws256.lu.erisoft.se> Subject: Re: stubify To: djgpp-workers AT delorie DOT com Date: Thu, 9 Jan 2003 13:22:20 +0100 (MET) In-Reply-To: <3E183620.EDBE0071@phekda.freeserve.co.uk> from "Richard Dawe" at Jan 05, 2003 01:41:52 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 > 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 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 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