This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [obish/dwarf2] Describe frame-base hack
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Mon, 26 Jan 2004 15:42:12 -0500
- Subject: Re: [obish/dwarf2] Describe frame-base hack
- References: <4015711E.6090005@gnu.org>
On Mon, Jan 26, 2004 at 02:57:18PM -0500, Andrew Cagney wrote:
> Hello,
>
> Stumbled across this during testing of symbol_ops. This adds a comment
> alerting the reader as to a problem.
There is already a FIXME describing this in symtab.h which answers your
guess below.
> Index: ChangeLog
> 2004-01-26 Andrew Cagney <cagney@redhat.com>
>
> * dwarf2read.c (read_func_scope): Document hack.
>
> Index: dwarf2read.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> retrieving revision 1.124
> diff -u -r1.124 dwarf2read.c
> --- dwarf2read.c 23 Jan 2004 22:41:28 -0000 1.124
> +++ dwarf2read.c 26 Jan 2004 19:54:06 -0000
> @@ -2211,6 +2211,15 @@
> it. */
> attr = dwarf_attr (die, DW_AT_frame_base);
> if (attr)
> + /* FIXME: cagney/2004-01-26: The DW_AT_frame_base's location
> + expression is being recorded directly in the function's symbol
> + and not in a separate frame-base object. I guess this hack is
> + to avoid adding some sort of frame-base adjunct/annex to the
> + function's symbol :-(. The problem with doing this is that it
> + results in a function symbol with a location expression that
> + has nothing to do with the location of the function, ouch! The
> + relationship should be: a function's symbol has-a frame base; a
> + frame-base has-a location expression. */
> dwarf2_symbol_mark_computed (attr, new->name, cu);
>
> list_in_scope = &local_symbols;
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer