Re: [hppa] FYI: confusion in unwind descriptor field meaning

[Randolph Chung <randolph at tausq dot org>]

ok, some more comments:

> 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:

gcc uses this to mean that the frame base has been saved to the stack.

>     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.

but it doesn't use this. This seems to be related to alloca?

> 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.

I don't know if you are trying to tackle any specific problem you have 
observed, but the current code works for gcc.

> 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.

Which compiler? gcc doesn't use the Large_frame_r3 flag, but HP 
compilers might, and if you have a tool that needs to use this flag, and 
it follows the documentation, perhaps we can support this *in addition 
to the current constructs* in gdb.

> 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...

Yes, I have seen this under hppa-linux for some hand coded asm functions 
too.

> 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).

It still does, and the fact is that the current unwinder code has 
evolved through many rounds of testing under hppa-linux. We still have a 
large number of testsuite failures under HPUX that really need to be 
investigated. The tricky part is that not only does gcc not follow the 
ABI precisely, iirc even the HP tools don't always follow the 
documentation precisely in some places. I think the only realistic thing 
to do is to empirically examine code that is not working and try to fix 
gdb to handle it. I agree with you that the current unwinder can use 
some cleaning up; unfortunately it is also rather fragile and subtle. 
I've tried to document interesting things I've found along the way, but 
the unwind data just isn't always very precisely describing what is 
happening in the prologue.

Dave has been working on adding dwarf2 support to gcc for both linux and 
hpux targets; perhaps one day we can rely on dwarf for better debugging.

randolph