Re: Unwinding CFI gcc practice of assumed `same value' regs

[Andrew Haley <aph at redhat dot com>]

Ulrich Drepper writes:
 > Andrew Haley wrote:
 > > Null-terminating the call stack is too well-established practice to be
 > > changed now.
 > 
 > Which does not mean that the mistake should hold people back.

Sure it does.  Not breaking things is an excellent reason, probably
one of the the best reasons you can have.

 > This is just one of the mistakes in the x86-64 ABI.  It was copied
 > from x86 and it was wrong there already.
 > 
 > > In practice, %ebp either points to a call frame -- not necessarily the
 > > most recent one -- or is null.  I don't think that having an optional
 > > frame pointer mees you can use %ebp for anything random at all,
 > 
 > Of course it means that.

Really?  Well, that's one interpretation.  I don't believe that,
though.  It's certainly an inconsistency in the specification, which
says that null-termination is supported, and this implies that you
can't put a zero in there.

 > > The right way to fix the ABI is to specify that %ebp mustn't be
 > > [mis]used in this way, not to add a bunch more unwinder data.
 > 
 > Nope.  The right way is to specify things like backtraces with the 
 > adequate mechanism.  I fully support adding the Dwarf3 unwinder 
 > requirements.

"All of these" might be the right way to go.  That is, keep
null-terminating the stack, strengthen the rules about what you might
do with %ebp, and extend debuginfo.

Andrew.