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.
