This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch rfc] Per-frame frame-base
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 26 Mar 2003 16:00:53 -0500
- Subject: Re: [patch rfc] Per-frame frame-base
- References: <3E820F82.6050803@redhat.com>
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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer