Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?

[Daniel Berlin <dan at dberlin dot org>]

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.