Re: [rfc; rfa:i386] Eliminate save_dummy_frame_tos

[Andrew Cagney <ac131313 at redhat dot 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 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