Integrating DWARF2 CFA info

Integrating DWARF2 CFA info

[Daniel Berlin]

So i've got the dwarf2 CFA info being used now, when available, to
find the location of a register.

However, i've run into an interesting issue.

The most logical place for this code, and where it is now, is in
generic_get_saved_register, and default_get_saved_register (to catch
the non-multiarch targets).

Instead of using FRAME_INIT_SAVED_REGS, we use the dwarf2 CFA info, if
available, and execute the CFA program up to the frame's PC, and setup
frame->saved_regs with the locations of the registers at that point.

This works fine.

However, I've noticed that there are a few multiarch ports that don't end up
using generic_get_saved_register at all.

SPARC jumps to mind.

It would seem a shame to not let these ports use the DWARF2 CFA info,
if it's available.
What can I do to get around this problem?

Should I move the code in generic_get_saved_register that checks for
the CFA info, calls the evaluator, into a seperate function, and call
it from sparc_get_saved_register as well?

This seems annoying, as it means any logic changes to
generic_get_saved_register to that code would have to be copied into
wherever else it's used as well.

gdbarch functions aren't stackable, so i can't just implement a
dwarf2_get_saved_register that uses the dwarf2 cfa info, and if it's
not available, calls the next lower level get_saved_register function.

This would seem to be the most elegant solution, if it was possible,
IMHO.
Andrew, would you mind if i made that function stackable?
If I do, would you like me to make it generic so that all of the
functions are stackable?

I would imagine the first is enough work that the second would be a
trivial extension, no?

I'm thinking I would just make them all function stacks, make the
set_gdbarch_* functions overwrite the top of the stack, and make it
generate push_gdbarch_* functions as well, that pushed to the top of
the stack.
We default to executing the function on the top of the stack, and that
function is responsible for calling a lower stack level function if it
wanted to.
So we'd have a get_gdbarch_next_* functions, which would find the next
lowest level function, given the current one, or something.

Is all of this work making them stackable even useful for anything else?
If not, i'm tempted to just say "screw SPARC" when i submit the
patches, add it to the TODO list, and be done with it.


-- 
"I have an answering machine in my car.  It says, "I'm home now.
But leave a message and I'll call when I'm out."
"-Steven Wright

Re: Integrating DWARF2 CFA info

[Andrew Cagney]

> So i've got the dwarf2 CFA info being used now, when available, to
> find the location of a register.

(What exactly does CFA mean.  I know what you're refering to, just not 
the acronym).


> gdbarch functions aren't stackable, so i can't just implement a
> dwarf2_get_saved_register that uses the dwarf2 cfa info, and if it's
> not available, calls the next lower level get_saved_register function.

I don't think a stack is applicable here.  As you move between frames 
the debug info could change and the get_saved_register() functions 
should adapt accordingly.  Having a stack would imply a specific 
heirichy and that isn't correct in this case.

	Andrew

Re: Integrating DWARF2 CFA info

[Daniel Berlin]

On Wed, 9 May 2001, Andrew Cagney wrote:

> > So i've got the dwarf2 CFA info being used now, when available, to
> > find the location of a register.
>
> (What exactly does CFA mean.  I know what you're refering to, just not
> the acronym).
>
Call Frame Annotation.

>
> > gdbarch functions aren't stackable, so i can't just implement a
> > dwarf2_get_saved_register that uses the dwarf2 cfa info, and if it's
> > not available, calls the next lower level get_saved_register function.
>
> I don't think a stack is applicable here.  As you move between frames
> the debug info could change and the get_saved_register() functions
> should adapt accordingly.  Having a stack would imply a specific
> heirichy and that isn't correct in this case.
Well, actually, IMHO, it is.
The CFA info gives us the location of all saved registers for the entire
procedure.
It's always correct, even in the presence of optimization.
Given the pc for the frame, it can tell you exactly where all the saved
registers are, at that particular point in time.
Therefore, it is strictly better to use the CFA info, than scan the
instructions.

So I see a strict hiearchy of what to use:
Dwarf2 CFA Info
<whatever else>

>
> 	Andrew
>
>

Re: Integrating DWARF2 CFA info

[Andrew Cagney]

> Well, actually, IMHO, it is.
> The CFA info gives us the location of all saved registers for the entire
> procedure.
> It's always correct, even in the presence of optimization.
> Given the pc for the frame, it can tell you exactly where all the saved
> registers are, at that particular point in time.
> Therefore, it is strictly better to use the CFA info, than scan the
> instructions.
> 
> So I see a strict hiearchy of what to use:
> Dwarf2 CFA Info
> <whatever else>

This assumes that dwarf2 info is more correct than some other sort of info.

	Andrew

Re: Integrating DWARF2 CFA info

[Daniel Berlin]

On Thu, 10 May 2001, Andrew Cagney wrote:

> > Well, actually, IMHO, it is.
> > The CFA info gives us the location of all saved registers for the entire
> > procedure.
> > It's always correct, even in the presence of optimization.
> > Given the pc for the frame, it can tell you exactly where all the saved
> > registers are, at that particular point in time.
> > Therefore, it is strictly better to use the CFA info, than scan the
> > instructions.
> >
> > So I see a strict hiearchy of what to use:
> > Dwarf2 CFA Info
> > <whatever else>
>
> This assumes that dwarf2 info is more correct than some other sort of info.

Which it is, as I've shown.
It will always be correct.
If not, the compiler is broken.

>
> 	Andrew
>

Re: Integrating DWARF2 CFA info

[Daniel Berlin]

On Thu, 10 May 2001, Andrew Cagney wrote:

> > Well, actually, IMHO, it is.
> > The CFA info gives us the location of all saved registers for the entire
> > procedure.
> > It's always correct, even in the presence of optimization.
> > Given the pc for the frame, it can tell you exactly where all the saved
> > registers are, at that particular point in time.
> > Therefore, it is strictly better to use the CFA info, than scan the
> > instructions.
> >
> > So I see a strict hiearchy of what to use:
> > Dwarf2 CFA Info
> > <whatever else>
>
> This assumes that dwarf2 info is more correct than some other sort of info.

Also, not only is it always correct, even in the presence of optimization
(unless the compiler is broken), but accessing it and using it is
architecture independent.
All the arch dependent stuff is on the gcc side.

In other words, it removes the need for making a new gdb port have to
have functions to scan prologue and epilogue code to find register saves
and whatnot.

Also, unlike the scanning, DWARF2 CFA gives you a virtual frame for inline
functions (if you want it), so you can treat them like normal functions
calls, and the user doesn't have to care that the function was inlined.

While some other debug format may come along that can provide this
kind of info, there is absolutely no indication people are even
developing new debug formats. Most compiler vendors seem perfectly
content with DWARF2, because you can always extend it to handle some
weird new language semantics by adding new tags and attributes.
Past that, it can already (in 2.0) handle almost all optimized code
situations, and 2.1 can handle *all* of them.
What else do you need from a debug format?

And if this debug format *did* come along, that gave somehow even
better info to us (which isn't really possible, but that's besides
the point), it would still maintain a strict ordering of prefernece.

<whatever the new debug info format is>
DWARF2 CFA info
<everything else>

So I don't quite see what your objection to a stack is. There certainly is
a strict ordering, and dwarf2 info is certainly more correct than what we
do now, in all cases.  It's always better, never worse.

 --Dan