This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfc; rfa:i386] Eliminate save_dummy_frame_tos
- From: Mark Kettenis <kettenis at chello dot nl>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: 13 Jun 2003 21:37:53 +0200
- Subject: Re: [rfc; rfa:i386] Eliminate save_dummy_frame_tos
- References: <3EE95C62.5060706@redhat.com>
Andrew Cagney <ac131313@redhat.com> 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