On 02/05/2014 07:58 AM, Jakub Jelinek wrote:
> On Wed, Feb 05, 2014 at 03:32:22PM +0000, Richard Sandiford wrote:
>> I think at the moment we're relying on the "DW_CFA_offset 15"s to
>> provide correct %r15 values on eh_return. Every non-leaf function
>> saves the stack pointer and the unwind routines track the %r15 save
>> slots like they would track any call-saved register. In other words,
>> the final eh_return %r15 comes directly from a save slot, without any
>> CFA-specific handling. If some frames omit the CFI for the %r15 save
>> then we'll just keep the save slot from the previous (inner) frame instead.
>
> CCing Richard Henderson into the discussion.
If the sp is saved for a given frame, we'll use that instead of the CFA when
unwinding to a previous frame. That should be unaffected by whether or not sp
is saved for any particular frame.
There appears to be code in uw_install_context_1 to handle a mix of sp-saving
and non-sp-saving frames. Given that s390 is pretty much the only target that
uses these paths, I suppose it could be broken. But if it is, it would surely
be better to fix than just say "it doesn't work".
> BTW, what is the reason why %r15 is saved/restored from the stack at all say
> for simple:
> void
> foo (void)
> {
> int a = 6;
> asm volatile ("# %0" : "+m" (a));
> }
>
> Is that some ABI matter where it effectively always uses requires to use
> some kind of frame pointer (which the saved previous stack pointer is)?
> It can surely make debugging without unwind info easier, ditto backtraces,
> on the other side it must have a runtime cost.
As far as I recall, the return address is in r14 so the ABI also saves r15 for
all non-leaf functions simply because it is practically free to do so with
store-multiple. This creates the familiar ra/fp unwinding chain. Given how
cheap it is to maintain this chain on s390, I see no particular call to break
it.
As for why r15 gets saved for this leaf example... I have no idea.
Seems like a bug to me, frankly.
r~
