From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17234 invoked by alias); 13 Jun 2003 20:36:07 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17168 invoked from network); 13 Jun 2003 20:36:04 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 13 Jun 2003 20:36:04 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E9C162B5F; Fri, 13 Jun 2003 16:36:00 -0400 (EDT) Message-ID: <3EEA35B0.4070809@redhat.com> Date: Fri, 13 Jun 2003 20:36: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-patches@sources.redhat.com Subject: Re: [rfc; rfa:i386] Eliminate save_dummy_frame_tos References: <3EE95C62.5060706@redhat.com> <86brx1zs32.fsf@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00480.txt.bz2 > Andrew Cagney writes: > > >> This is a multi-part message in MIME format. >> --------------050407020306070609080700 >> Content-Type: text/plain; charset=us-ascii; format=flowed >> Content-Transfer-Encoding: 7bit >> >> Hello, >> >> This patch removes the need for setting the save_dummy_frame_tos method >> (d10v and i386). Instead the frame ID stack addr returned by >> push_dummy_call is saved (by generic_save_dummy_frame_tos) and used as >> the dummy breakpoint ID. >> >> The i386 and d10v don't show any regressions. >> >> Mark, look right? > > > Looks good to me. We can make similar changes to amd64, but if you > don't want to make those, I'll do a followup patch to yours. I feel lucky .... >> I'd like to add a comment to the ``return sp + 8'' only I'm not actually >> sure what's going on here :-/ > > > It certainly deserves a comment. I'm just not sure. This "+ 8" is > all over the place (i386_frame_this_id, i386_sigtramp_frame_this_id, > i386_unwind_dummy_id). It's there, since all frame unwinders for a > given target have to agree (within a certain margin) on the defenition > of the stack address of a frame. Otherwise frame_id_inner() won't > work correctly. Since DWARF2/GCC uses the stack address *before* the > function call as a frame's CFA. On the i386, when %ebp is used as a > frame pointer, the offset between the contents %ebp and the CFA as > defined by GCC. Stolen. I've checked in the attached. It's slightly different to the original in that: - it also tweaks x86-64 and alpha - when unwind_dummy_id_p it always uses generic_save_dummy_frame_tos which forces the 4 ducks: -- push_dummy_call -- unwind_dummy_id -- the dummy breakpoint's frame ID -- the dummy frame's stack addr to be in a row. I'll follow-up with extra gdbarch comments. Andrew