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~