From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27863 invoked by alias); 7 Mar 2003 20:59:56 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27854 invoked from network); 7 Mar 2003 20:59:53 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by 172.16.49.205 with SMTP; 7 Mar 2003 20:59:53 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6/8.12.5) with ESMTP id h27Kxhhs000574; Fri, 7 Mar 2003 21:59:43 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id h27KxhVE029880; Fri, 7 Mar 2003 21:59:43 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id h27KxgX1029877; Fri, 7 Mar 2003 21:59:42 +0100 (CET) Date: Fri, 07 Mar 2003 20:59:00 -0000 Message-Id: <200303072059.h27KxgX1029877@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@redhat.com CC: gdb@sources.redhat.com Subject: Unwinding dummy frames on the i386 X-SW-Source: 2003-03/txt/msg00137.txt.bz2 Hi Andrew, After you committed the unwind_dummy_id stuff, I'm having some problems getting the i386 target working again. I tried using generic_save_dummy_frame on this target. This works fine if we're unwinding from a normal frame into a dummy frame. However, if we're unwinding from a sentinel frame, things start to get a bit difficult. This basically happens if we've hit the special breakpoint upon return from the called function. On the i386 returning from a function pops the return address from the stack. Since the return address was pushed by GDB an accounted for in the stack pointer passed to generic_save_dummy_frame_tos(), things don't match up. This fixable in i386_unwind_dummy_id(), however things are a bit more complicated. If a function returns a struct, the caller is supposed to push as a "hidden" parameter the address of a bit of memory where the called function is supposed to store the struct. This extra push is again accounted for in the stack pointer passed to i386_save_dummy_frame_tos(). However, since the called function is supposed to remove this address from the stack, again things don't match up for the unwind-from-sentinel case. I don't see a clean way to fixup this. For now I've worked around this by having my own do-nothing i386_save_dummy_frame_tos(), and having i386_unwind_dummy_id() return contents of the (saved) frame pointer register for the frame's base. Is there a better way to solve this? Mark