From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Berlin <dan@cgsoftware.com>
To: gdb@sources.redhat.com
Subject: Integrating DWARF2 CFA info
Date: Mon, 07 May 2001 12:08:00 -0000
Message-id: <87ae4p3rkz.fsf@dynamic-addr-83-177.resnet.rochester.edu>
X-SW-Source: 2001-05/msg00091.html

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