From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14479 invoked by alias); 13 Jun 2003 19:38:08 -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 14383 invoked from network); 13 Jun 2003 19:38:05 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by sources.redhat.com with SMTP; 13 Jun 2003 19:38:05 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p2/8.12.5) with ESMTP id h5DJbrTN000411; Fri, 13 Jun 2003 21:37:53 +0200 (CEST) (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.6p2/8.12.6) with ESMTP id h5DJbr1u000922; Fri, 13 Jun 2003 21:37:53 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6/Submit) id h5DJbrBE000919; Fri, 13 Jun 2003 21:37:53 +0200 (CEST) To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc; rfa:i386] Eliminate save_dummy_frame_tos References: <3EE95C62.5060706@redhat.com> From: Mark Kettenis Date: Fri, 13 Jun 2003 19:38:00 -0000 In-Reply-To: Andrew Cagney's message of "Fri, 13 Jun 2003 01:08:50 -0400" Message-ID: <86brx1zs32.fsf@elgar.kettenis.dyndns.org> X-SW-Source: 2003-06/txt/msg00476.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'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. Mark