[hppa] FYI: confusion in unwind descriptor field meaning

[Joel Brobecker]

Hello,

This is really for anybody's FYI, and maybe Randolph if he'd like to
dig in some of the issues with me.

This is something I'm still working on, so I haven't verified my theory
just yet. But I think there is a confusion in the meaning of Save_SP
in the unwind descriptor. The document I have says:

    18. Save_SP (bit 27): One if the entry value of SP is saved by this
        regions entry sequence in the current frame marker (current_SP - 4);
        zero otherwise.

It doesn't say that the frame has a frame base register. For this, we
have another field:

    25. Large_frame_r3 (bit 34): One if gr3 is changed during the entry
        sequence to contain the address of the base of the (new) frame.

So I think the following test is wrong:

      /* Handle code with and without frame pointers.  */
      if (u->Save_SP)
        cache->saved_regs[reg].addr = offset;
      else
        cache->saved_regs[reg].addr = (u->Total_frame_size << 3) + offset;

I think it should read something like:

      if (u->Large_frame)

or something like this. Or perhaps we should check the base register
and if it is r3, then only use the offset. Not sure yet.

The problem I'm really working on is not affected by the above, it's
more about finding out that the function, although the Alloca flag is
not set, has a variable-size frame. I need to use the Large_frame flag
to determine that we have a frame base, and therfore use r3 as the frame
base if the previous_SP has been saved there.

Generally speaking, there have been fixing a large number of issues our
customers have helped us find out. For instance, we have found code
pieces where the unwind record shows a discontinuous region: No entry
point. So the address start of the region does not point at the function
start and hence no prologue, with the consequences you can imagine when
we scan that region looking for prologue instructions...

Unfortunately, I'm unable to contribute either the examples provided
by the customer (they often come in the form of a gigantic executable
along with a core file, no source), nor the fix, because the compiler
we use made some tweaks to the unwind data so that the HP unwinder is
able to unwind through GCC code as well as HP code (I understand GCC
made some small deviations from the ABI, or used to make maybe).

--
Joel