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

[Jim Blandy <jimb@zwingli.cygnus.com>]

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.

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.

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.

(This would also allow us to move some odd HP-UX-specific stuff like
LOC_THREAD_LOCAL_STATIC out of the GDB core and into an HP-specific
module.)