This is the mail archive of the
mailing list for the GDB project.
Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- To: Petr Sorfa <petrs at caldera dot com>
- Cc: Daniel Berlin <dan at dberlin dot org>,Daniel Jacobowitz <drow at mvista dot com>, <gdb at sources dot redhat dot com>
- Date: 23 Jan 2002 18:43:21 -0500
- Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
- References: <Pine.LNX.email@example.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
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
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