var-tracking and s390's LM(G)

Richard Henderson rth@redhat.com
Thu Feb 6 01:46:00 GMT 2014


On 02/05/2014 02:30 PM, Ulrich Weigand wrote:
> Jakub Jelinek wrote:
>> On Wed, Feb 05, 2014 at 10:26:16PM +0100, Ulrich Weigand wrote:
>>> Actually, now I think the problem originally described there is still
>>> valid: on s390 the CFA is *not* equal to the value at function entry,
>>> but biased by 96/160 bytes.  So setting the SP to the CFA is wrong ...
>>
>> Such biasing happens on most of the targets, e.g. x86_64 has upon function
>> entry CFA set to %rsp + 8, i?86 to %esp + 4.
> 
> Ah, but that's a different bias.  In those cases it is still correct
> to *unwind* SP to the CFA, since that's the value SP needs to have
> back in the caller immediately after the call site.
> 
> On s390, the call/return instructions do not modify the SP so the
> SP at function entry is equal to the SP in the caller after return,
> but neither of these is equal to the CFA.  Instead, SP points to
> 96/160 bytes below the CFA ...   Therefore you cannot simply
> unwind SP to the CFA.

I was about to reply the same to Jakub, Ulrich beat me to it.

Basically, the CFA has been defined "incorrectly" for s390, but it hasn't
mattered since they record the save of the SP.  But the result is that you
can't stop recording the save of SP without also adjusting how the CFA is defined.

Which _can_ be done, in a way that's fully compatible with all of the existing
unwinding.  But certainly shouldn't be attempted at this stage of development.


r~



More information about the Gcc-patches mailing list