Re: [libunwind] libunwind and .savepsp

[David Mosberger]

>>>>> On Mon, 13 Sep 2004 12:12:40 -0700 (PDT), Anthony C Brewer 
>>>>> <address@hidden> said:

  Anthony> I've encountered a problem with unwinding through
  Anthony> particular C functions where gcc is saving the ar.pfs and
  Anthony> rp on the stack instead of in registers.  The prologue code
  Anthony> created for the affected function is below, neither gdb nor
  Anthony> the unwind library functions can find any of the call stack
  Anthony> above this function.  If I patch the code to save the
  Anthony> ar.pfs and rp in registers instead, unwinding works find.
  Anthony> Is this a limitation of the unwind library, or is gcc
  Anthony> creating bad prologue code?

It appears to be a toolchain-bug.

  Anthony> (I have libunwind 0.98 and gcc 3.2.3).

  Anthony> adds r17 = -416, r12
  Anthony> .savepsp pr, 416
  Anthony> st8 [r17] = r20, 16

The GNU assembler translates this into:

         P7:pr_psprel(pspoff=0x10-0x1a0)

which would correspond to an offset of -400, not -416.

Unfortunately, the assembly reference manual seems rather ambiguous on
how the offset in the .savepsp directive should get translated.
However, the Intel assembler translates the above into:

        P7:pr_psprel(pspoff=0x10-0x1b0)

so it looks to me like GAS may be at fault here.

Jim, HJ, do you agree?

Unfortunately, this means that there may be code out there with such
bad unwind info.  I don't think I can work around the bug in
libunwind, since there is no way to tell which assembler was being
used.  The question then is how much such code there may be.  It
appears only save-locations with psp-relative offsets are affected,
which GCC seems to use only when variable-size stack-frames are in use
(e.g., due to a variable-sized array or due to "alloca").  Even then
the bug will show only when a preserved register gets spilled to the
memory-stack, which is relatively rare.  Overall, I suspect it's
extremely rare for this bug to get triggered, which is probably why it
went unnoticed for so long.

For now, I'll add a test-case to the libunwind test-suite which should
catch this problem.  If we decide that GAS is at fault, we should be
able to fix it easily.

Thanks,

        --david