This is the mail archive of the gdb-patches@sources.redhat.com 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] |
On Wed, Mar 26, 2003 at 03:37:22PM -0500, Andrew Cagney wrote:
The implementation is very much modeled on the frame-unwind code. Debug readers are expected to register their own high level frame-base handler.
So what will the process for getting a dwarf2-debug-info frame registered look like?
How will we figure out that this function has dwarf2 debug info? It's not trivial... we don't have that information around any more on a per-PC basis.
I'll have to think.
+/* Assuming that a frame is `normal', return the address of the first + local variable, or 0 if the information isn't available. NOTE: + This address is really only meaningful to the frame's high-level + debug info. Typically, the argument and locals share a single + base-address. */ +extern CORE_ADDR get_frame_locals_address (struct frame_info *); + +/* Assuming that a frame is `normal', return the address of the first + parameter, or 0 if that information isn't available. NOTE: This + address is really only meaningful to the frame's high-level debug + info. Typically, the argument and locals share a single + base-address. */ +extern CORE_ADDR get_frame_args_address (struct frame_info *); +
Address of the first parameter / address of the first argument isn't correct I think. It's the base address for parameters and the base address from locals. They're likely to be the same but with different offsets.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |