[hppa] FYI: confusion in unwind descriptor field meaning

[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

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

[Randolph Chung]

Joel,

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

Be careful here, some of this is to work around gcc's interpretation of 
these fields, which does not always correspond to the documentation. gcc 
only uses a few of the bits in the unwind record.

Dave Anglin (pa gcc maintainer) is the expert on these issues.

I only have a few minutes now, will respond in more detail to your two 
messages later this evening.

thanks and I do hope to have a little more time to start looking at gdb 
again.

randolph

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

[Joel Brobecker]

> Be careful here, some of this is to work around gcc's interpretation of 
> these fields, which does not always correspond to the documentation. gcc 
> only uses a few of the bits in the unwind record.

Grumble.

Yes, I know. It's the reason why I never got around to submit the few
changes we made locally. Our GCC has some local changes that make the
unwind descriptor more compatible between the two models. I am still
asking the details to the hppa specialist at AdaCore, but it seems
that starting with GCC 3.4, the frame was setup in a more compatible
way already. If you're interested, I'll let you know the details of
our implementation.

-- 
Joel

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

[Randolph Chung]

Joel Brobecker wrote:
>>Be careful here, some of this is to work around gcc's interpretation of 
>>these fields, which does not always correspond to the documentation. gcc 
>>only uses a few of the bits in the unwind record.
> 
> Grumble.
> 
> Yes, I know. It's the reason why I never got around to submit the few
> changes we made locally. Our GCC has some local changes that make the
> unwind descriptor more compatible between the two models. I am still
> asking the details to the hppa specialist at AdaCore, but it seems
> that starting with GCC 3.4, the frame was setup in a more compatible
> way already. If you're interested, I'll let you know the details of
> our implementation.

Well, I think we need to work with upstream gcc. I know Dave has done
some work to improve this with more recent versions of gcc.

Let's try to document all the variations of compilers we claim to work
with (gcc-3.x, gcc-4.x, HP aCC, etc) and we'll try to come up with
something that works "everywhere".

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

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

[Randolph Chung]

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

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

[Joel Brobecker]

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

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

[Randolph Chung]

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

How do you find the end of the prologue without consulting the unwind
data? Right now one heuristic is "scan the code until you hit a branch",
which works but might mean you scan way too much code. I'm also not
certain if this will work correctly for things like alloca, but it might.

For that matter, how do you find the beginning of the function without
unwind data? Right now the hppa backend can determine this even in the
absence of other debug (stabs, dwarf) info, although it might end up
printing the wrong function name in a backtrace.

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

Making gdb more compiler independent is of course a good thing, but I
don't know that we want to get rid of the unwind record altogether.
OTOH, if you can combine all the prologue analysis code in hppa-tdep.c
and make it more robust, I think it will certainly be a good thing.

randolph

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

[Jim Blandy]

On 11/11/05, Randolph Chung <randolph@tausq.org> wrote:
> How do you find the end of the prologue without consulting the unwind
> data? Right now one heuristic is "scan the code until you hit a branch",
> which works but might mean you scan way too much code. I'm also not
> certain if this will work correctly for things like alloca, but it might.

This is a question all the prologue analyzers have to answer.  You can
either stop when you reach the current PC, or stop when you see an
instruction you don't recognize.

> For that matter, how do you find the beginning of the function without
> unwind data?

Linker symbols.  If you don't have them, then prologue analysis isn't useful.

> OTOH, if you can combine all the prologue analysis code in hppa-tdep.c
> and make it more robust, I think it will certainly be a good thing.

In my experience, the new analysis framework (which I've kind of been
forgetting about for a while now) makes things a lot more robust.  I
wrote it because I was getting fed up with corrupted backtraces
debugging GDB on the S/390.  With the new framework, I got a
multi-page backtrace through optimized code the first time.  It makes
a big difference.

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

[Jim Blandy]

Just to be clear, though --- I think Dwarf CFI is preferable to
prologue analysis.  Even if we can do a decent job recovering
unwinding data, the compiler actually *knows* it, and ought to just
tell us.

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

[Randolph Chung]

>>For that matter, how do you find the beginning of the function without
>>unwind data?
> 
> Linker symbols.  If you don't have them, then prologue analysis isn't useful.

This is what I meant - on hppa, even without linker symbols, we can
still do prologue analysis because the ABI mandates unwind records. So
we can actually do unwinding more robustly based on the unwind records.
This is especially useful when you have mixed code compiled with
different flags and/or have been stripped.

We have this comment in hppa-tdep.c:

    /* We used to use frame_func_unwind () to locate the beginning of the
       function to pass to skip_prologue ().  However, when objects are
       compiled without debug symbols, frame_func_unwind can return the
wrong
       function (or 0).  We can do better than that by using unwind
records.  */

>>OTOH, if you can combine all the prologue analysis code in hppa-tdep.c
>>and make it more robust, I think it will certainly be a good thing.
> 
> In my experience, the new analysis framework (which I've kind of been
> forgetting about for a while now) makes things a lot more robust.  I
> wrote it because I was getting fed up with corrupted backtraces
> debugging GDB on the S/390.  With the new framework, I got a
> multi-page backtrace through optimized code the first time.  It makes
> a big difference.

Yes, I saw some of the discussions about the new framework and I think
it's a very good thing. gdb on hppa-linux can do pretty good backtraces
now with optimized code. On hpux we still have some work to do. In
either case, as Mark pointed out, the code is rather ugly so doing some
cleanup with some more structure will be nice.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

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

[Jim Blandy]

On 11/11/05, Randolph Chung <randolph@tausq.org> wrote:
> >>For that matter, how do you find the beginning of the function without
> >>unwind data?
> >
> > Linker symbols.  If you don't have them, then prologue analysis isn't useful.
>
> This is what I meant - on hppa, even without linker symbols, we can
> still do prologue analysis because the ABI mandates unwind records. So
> we can actually do unwinding more robustly based on the unwind records.
> This is especially useful when you have mixed code compiled with
> different flags and/or have been stripped.

Hmm.  Is it possible to find a function's entry point from a PC within
that function's code given only the unwind records?  If the detailed
contents of the unwind records are difficult to interpret accurately,
but we can accurately recover entry points from them, and prologue
analysis works, then we could use the unwind records *only* to
discover entry points, and then use prologue analysis to actually get
the unwind information.

I'm sounding like some kind of prologue analysis fanatic here, but
really I'm not.   We should make the best use of the techniques and
information available, and it sounds to me like prologue analysis is
comparable with the alternatives here, if we can find the information
it needs.

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

[Randolph Chung]

> Hmm.  Is it possible to find a function's entry point from a PC within
> that function's code given only the unwind records?  If the detailed

There is one unwind record for each function. The unwind record contains
the start and end address of the function. So yes, given a pc, we can
find the unwind record and recover the starting address of the function.

> contents of the unwind records are difficult to interpret accurately,
> but we can accurately recover entry points from them, and prologue
> analysis works, then we could use the unwind records *only* to
> discover entry points, and then use prologue analysis to actually get
> the unwind information.

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

Now, there is a trick to this -- how do we know we are after the
prologue? Currently, we look at the unwind record which tells us what
information is stored in the frame, and we do code analysis to determine
the pc where all the information that the unwind record says should be
in the frame has been stored in the frame.

We used to not do this, and in fact hppa-tdep.c has a few variations of
ways to "skip the prologue" :-(

The more efficient way to determine the end of the prologue is to use
debug info (i.e. we do what most backends do with
find_pc_partial_function and find_pc_line). Sometime last year I changed
this to always do code walking to better work with optimized functions.
Note that in this case we are only counting instructions and not really
"remembering" where things are.

Then we check to see if the pc is after the prologue. If it is not, we
do more prologue analysis and code walking to figure out what to do.

You might think this is all rather circular, and it is. I agree with
what you said below, that is:

> I'm sounding like some kind of prologue analysis fanatic here, but
> really I'm not.   We should make the best use of the techniques and
> information available, and it sounds to me like prologue analysis is
> comparable with the alternatives here, if we can find the information
> it needs.

I'm all for cleaning up the code; I just think we need to be careful
because of all the "twists" in the hppa ABI... especially on HPUX :(
Just take a look at hppa_hpux_push_dummy_code sometime. <sigh>

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

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

[Jim Blandy]

On 11/11/05, Randolph Chung <randolph@tausq.org> wrote:
> > Hmm.  Is it possible to find a function's entry point from a PC within
> > that function's code given only the unwind records?  If the detailed
>
> There is one unwind record for each function. The unwind record contains
> the start and end address of the function. So yes, given a pc, we can
> find the unwind record and recover the starting address of the function.

Okay, that's interesting.

> Well....
> 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.
>
> Now, there is a trick to this -- how do we know we are after the
> prologue? Currently, we look at the unwind record which tells us what
> information is stored in the frame, and we do code analysis to determine
> the pc where all the information that the unwind record says should be
> in the frame has been stored in the frame.

I think it's best to just not think in terms of "before the prologue"
/ "after the prologue" / "end of the prologue".  Your instructions are
going to get mixed together by scheduling anyway.  What you can count
on instead is that, at any given point in the function, whether at its
entry point, in the midst of the prologue, or deep into the guts of
the function, there is some way to do the unwinding.  Otherwise, the
function itself couldn't return.  (Backtracing out of "never-return"
functions presents special difficulties exactly because this isn't
true there.)

That's why I say prologue analysis should run from the entry point up
to the current PC, or until it reaches an unrecognized instruction. 
In the first case, it's obviously correct to stop.  In the second
case, since prologue analysis is inevitably a conservative
approximation to actually running the code live, the only technically
correct thing to do with an unrecognized instruction is throw away all
the information you've gathered --- after all, that instruction could
potentially invalidate all of it.  But in most cases, whatever you've
accumulated up to that point is a decent approximation of the right
thing, so it's better to just stop than to throw everything away.

> I'm all for cleaning up the code; I just think we need to be careful
> because of all the "twists" in the hppa ABI... especially on HPUX :(
> Just take a look at hppa_hpux_push_dummy_code sometime. <sigh>

I don't know what state the test results from HPPA are in (please
don't read any criticism in that), but I don't think we would need to
tolerate any regressions from the change.  What's a real threat to
progress is if there are so many variations we care about that it
becomes difficult to test.

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

[Randolph Chung]

> I don't know what state the test results from HPPA are in (please
> don't read any criticism in that), but I don't think we would need to
> tolerate any regressions from the change.  What's a real threat to
> progress is if there are so many variations we care about that it
> becomes difficult to test.

Test Run By tausq on Wed Nov  9 07:48:22 2005
Native configuration is hppa-unknown-linux-gnu

                === gdb Summary ===

# of expected passes            10813
# of unexpected failures        57
# of unexpected successes       1
# of expected failures          42
# of known failures             42
# of unresolved testcases       2
# of unsupported tests          3

HPUX is in much worse shape I'm afriad. I don't know the status of the
BSD port.

I believe we only have the following "actively" maintained configurations:

hppa-*-linux
hppa-*-openbsd
hppa-*-hpux*
hppa2.0w-*-hpux*
hppa64-*-hpux*

Which is still a lot, but not unmanagable yet. I somewhat actively
maintain and test the Linux port, and I can test the HPUX
configurations. I know nothing about BSD.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

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

[Daniel Jacobowitz]

On Sat, Nov 12, 2005 at 01:07:40PM +0800, Randolph Chung wrote:
> HPUX is in much worse shape I'm afriad. I don't know the status of the
> BSD port.
> 
> I believe we only have the following "actively" maintained configurations:
> 
> hppa-*-linux
> hppa-*-openbsd
> hppa-*-hpux*
> hppa2.0w-*-hpux*
> hppa64-*-hpux*
> 
> Which is still a lot, but not unmanagable yet. I somewhat actively
> maintain and test the Linux port, and I can test the HPUX
> configurations. I know nothing about BSD.

This is where I have to ask...

Does anyone still use the HP/UX native aCC support?  I'm talking
about hpacc-abi.c and the C++ bits of hpread.c.  I don't think GNU C++
on HP/UX uses any of this code.

I currently have access to an HP/UX system, with both the GNU and HP
tools.  I'm willing to go through and fix up the SOM support for the
GNU tools, but I think doing aCC would be a little more than I could
handle.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Randolph Chung]

> Does anyone still use the HP/UX native aCC support?  I'm talking
> about hpacc-abi.c and the C++ bits of hpread.c.  I don't think GNU C++
> on HP/UX uses any of this code.

Indeed g++ doesn't use those. jda has been working on improving 
dwarf-based debug and EH support for hpux in gcc.

> I currently have access to an HP/UX system, with both the GNU and HP
> tools.  I'm willing to go through and fix up the SOM support for the
> GNU tools, but I think doing aCC would be a little more than I could
> handle.

If you could, I think the SOM based solib support in gdb is rather 
broken. I think it's not mapping the libraries quite properly. Dave has 
seen problems where printing the address of a shlib function shows an 
unrelocated address...

Can I interest you in looking into these? :)

i would say if people are interested in HP toolchain, they can use wdb. 
The HP toolchain support in gdb is probably not working after all the 
code reorg anyway. MEC used to post test results for gdb on hpux using 
aCC but I haven't heard from him for a long time.

just my 2 cents :)
randolph

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

[Joel Brobecker]

> 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

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

[Daniel Jacobowitz]

On Fri, Nov 11, 2005 at 10:04:26PM -0800, Joel Brobecker wrote:
> 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.

If you're going to do this, I recommend using the prologue analysis
framework Jim posted, which hopefully we'll have merged by then.  If we
haven't, well, an active user of it will make it easier.

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

A good prologue analyzer may just want to go until it sees something
confusing.  Depending on the peculiarities of the architecture, this
may be enough.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Joel Brobecker]

> If you're going to do this, I recommend using the prologue analysis
> framework Jim posted, which hopefully we'll have merged by then.  If we
> haven't, well, an active user of it will make it easier.

There was some discussion about redesigning it a bit at the time.
I think it was something to make the analyser use callbacks in
the tdep code, as opposed to us calling the appropriate routines
in the analyzer. Is this still in the air (or maybe I am just
confused)? 

-- 
Joel

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

[Daniel Jacobowitz]

On Sun, Nov 13, 2005 at 10:22:55AM -0800, Joel Brobecker wrote:
> > If you're going to do this, I recommend using the prologue analysis
> > framework Jim posted, which hopefully we'll have merged by then.  If we
> > haven't, well, an active user of it will make it easier.
> 
> There was some discussion about redesigning it a bit at the time.
> I think it was something to make the analyser use callbacks in
> the tdep code, as opposed to us calling the appropriate routines
> in the analyzer. Is this still in the air (or maybe I am just
> confused)? 

Maybe? :-)

I tend to review things backwards in time; it's going to be a while
before I can work my way back to Jim's post again.  I need to play
around with it before I'll have an opinion.

-- 
Daniel Jacobowitz
CodeSourcery, LLC