This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> If we have an unwind record (and we should for any ABI-conforming
> function), and the pc is after the prologue, then theoretically we don't
> need to do prologue analysis.

Just to throw a bit my twist on this interesting discussion :)

This is of course in theory, but the problem is that we're seeing
deviations from the ABI. GCC mades its own changes, we at AdaCore
were more or less forced to change a few other things too (mostly
IIRC to make sur that the HPUX unwinder would be able to unwind
mixed HP/GCC code), and now I'm learning that even the HP C compiler
might have its own little modifications. So there is really no compiler
we can trust in following the manufacturer's documentation.

So trying to interpret the unwind record properly seems pretty tricky
to get right on HP/UX. I'm starting to agree with Jim that it might
be a good to do prologue scanning regardless of where we are. Provided
that reading memory regions in the inferior (analyzing instruction after
instruction) is not too slow, the performance should still be pretty
good.

I used to think that PA-Risc is a complex chip. It is, in a sense,
at least for the compiler maintainers. But for unwinding, I'm definitely
seeing patterns, and all the examples I've seen so far seem (only seem)
to indicate that prologue analysis should be relatively easy to do and
get right.

I think this begs for an experiment, which I hope I'll be able to make
sometime during the winter. I can start with the code we have, since
we already have a lot of code that analyzes the prologue, and see how
to reconstitute the information we would otherwise get from the unwind
record.

On the other hand, we're starting to collect a lot of data, and there
may be some ways to interpret this information properly. If we do, I
think one good thing would be to isolate the actual interpretation
from the unwinder. Move all the knowledge of how to read that record
away, so that the unwinder has an interface that doesn't depend on
the compiler.

Randolph I think raised a very good point regarding the computation
of the end of the prologue, though. I don't know if we can determine
this without the help of the unwind record. For this, I don't have
enough experience with that chip.

One last precision, regarding the unwind record. Although probably
99.9% of the time we have one unwind record = one function, I learned
from a customer report that this is not always the case. Sometimes,
one function will have more than one unwind record. So an unwind
record covers a region. It may or may not have a prologue, and may
or may not have an epilogue. Fortunately, this is something we can
handle thanks to the Region_description field.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]