This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
- From: Daniel Berlin <dan at dberlin dot org>
- To: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Cc: Petr Sorfa <petrs at caldera dot com>, Daniel Jacobowitz <drow at mvista dot com>, <gdb at sources dot redhat dot com>
- Date: Wed, 23 Jan 2002 19:16:59 -0500 (EST)
- Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
On 23 Jan 2002, Jim Blandy wrote:
>
> Daniel B. submitted patches to allow GDB to handle arbitrary Dwarf 2
> location expressions. However, the initial patch simply extended the
> functions that care about symbol locations (like read_var_value, for
> example) with another case that evaluated a Dwarf 2 location
> expression.
>
> However, I felt it was important to keep the core of GDB independent
> of any particular debug representation. Daniel B. was very
> accommodating, and revised the patch to introduce a new, "neutral"
> expression representation, and translate Dwarf 2 location expressions
> into that form. I think I had some concerns about the exact way it
> had been done, but I don't remember --- in general it was fine. I
> don't know what happened to the patch, but I don't think it ever got
> approved.
Nope, but that's okay.
>
> But while I feel pretty good about the "keep GDB's core independent of
> the debug formats" rule, I felt pretty bad about introducing what
> amounted to an exact duplicate of the Dwarf 2 location list
> interpreter, with the constants renamed. Surely that wasn't
> the right thing.
Almost an exact duplicate, i removed some opcodes and whatnot that were
pointless for us.
>
> Another approach occurred to me just now that I wish I had thought of
> when Daniel B.'s patch first appeared. If the core of GDB could
> define a structure of functions (resembling `struct cp_abi_ops',
> `struct target_ops', etc.) that allowed a debug reader to provide its
> own set of functions for finding variables, describing their locations
> in English, and everything else we do with `enum address_class' now,
> then that would make it easy and clean to use straight Dwarf 2
> location expressions, without any translation into an allegedly
> "neutral" representation, and without contaminating the core of GDB.
I think i mentioned this a few times as the cleanest way to also be able
to get rid of psymtabs for dwarf2, and use .debug_aranges/pubnames/etc.
It would let you make stabs use psymtabs internally, and make dwarf2 less
memory intensive and faster to load.