From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22356 invoked by alias); 8 Mar 2003 15:20:21 -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 22349 invoked from network); 8 Mar 2003 15:20:19 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by 172.16.49.205 with SMTP; 8 Mar 2003 15:20:19 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1826E2A9C; Sat, 8 Mar 2003 10:20:09 -0500 (EST) Message-ID: <3E6A0A28.9000304@redhat.com> Date: Sat, 08 Mar 2003 15:20:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: Unwinding dummy frames on the i386 References: <200303072059.h27KxgX1029877@elgar.kettenis.dyndns.org> <3E691984.4030207@redhat.com> <200303081142.h28Bg1BL035199@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00140.txt.bz2 > Date: Fri, 07 Mar 2003 17:13:24 -0500 > From: Andrew Cagney > > > 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? > > Can i386_save_dummy_frame_tos() save the `frame pointer register' that > the unwind_dummy_id() method later returns? > > If reading the current value of FP_REGNUM from current_regcache is OK > the answer is yes. Yes. Just add a comment to gdbarch.sh saying that tos's successor needs to be explicitly parameterized with the new regcache (along with anything else that might prove useful - old regcache, struct_addr, bp addr :-). > Hmm, in that case it's probably an even better > idea to actually set the frame pointer register to the top-of-stack in > i386_save_dummy_frame_tos(). That way, we won't have a problem when > there are several frameless function calls in a row. Is writing into > current_regcache acceptable? Shouldn't the push arguments code have already adjusted the FP? Anyway, regardless, you want to add frame_align() to the i386 architecture vector. It forces a non-empty correctly aligned dummy frame (thus eliminating the frameless dummy frame problem) (but read the comments that go with the call). > > While the TOS in save_dummy_frame_tos() might have once stood for > top-of-stack, there isn't anything saying that it has to be the stack > top. A better name for tha functioin's successor would be > save_dummy_frame_id() > > Agreed. Andrew