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

Joel Brobecker
2005-11-11T00:10:24Z

Hey Randolph,

[regarding Save_SP and Large_frame]

I think I'm starting to slowly get the big picture. Obviously not
as simple as I thought. On top of that, GNAT Pro has some internal
modifications in that area, and I'm still trying to create the list
of such modifications. The expert in the company lives in France but
tomorrow is a holiday, so I'll have to wait for monday to get some
answers.

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

I'm starting to understand why. The bug I was working on came from
code provided to our customer by Oracle. It seems that code was built
using the HP compiler, as opposed to GCC.

Given David and your feedback regarding these two flags, it looks like
the above can be safely modified into (u->save_SP || u->Large_frame).
Not a big worry for me at the moment, though.

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

This is not important to this debate, but I'd be interested in seeing
the asm, to see how you can create unwind records saying that the region
has no entry/exit point.

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

After your feedback, I'm starting to think that this whole unwind
record thing is a wasp nest. This is loud thinking at this stage,
but let me suggest something heretical: How about to stop using
the unwind record to do the unwinding? We scan the prologue as we've
always done, and collect all the information, including the fact that
the function has a frame pointer or not. Then we don't need use
the unwind record, except maybe to determine the function start
address. I think we might even be able to dump the FP_REGNUM
entirely.

The good thing is that I don't think we'll need that many changes
to the code to get to that point. Improve a bit the code scanner
to retrieve the information that we normally dig out of the unwind
record, and we should have something at least marginally working.
The other advantage is that now the debugger doesn't need to know
what compiler produced the object. So I'll be able to share the changes
we make internally too. What do you think?

Long term: There was a patch recently posted about a finite-state
machine system that could be used to do prologue analysis in a simpler
and more mechanical way. There have been some design suggestions
made, so it's going to be a while before it becomes available. But
this is a logical extension of the idea above.

Here is what I suggest: I can't promise that I'll have time for this,
as AdaCore is going to start preparing a new release of GNAT Pro at
the end of this year, and I still have a bit of work to get ready for
this. But I would like to continue collecting all the information you
have provided me, plus some info about our own changes, stir it with
the experience I've developped in the past year fixing bugs on this
platform, and try this new idea of dumping the unwind record. I will
try first with our debugger, so that I can try the debugger with our
compiler too. But I'll send patches as I make progress.

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

That would be a very good improvement indeed, but would still leave
us with the problem of non-GCC compiled code, as well as system
libraries.

--
Joel