Re: [rfc; rfa:i386] Eliminate save_dummy_frame_tos

[Mark Kettenis <kettenis@chello.nl>]

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