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

[Daniel Berlin <dan at dberlin dot org>]

On Wed, 23 Jan 2002, Andrew Cagney wrote:

> > 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.
> 
> 
> 
> http://sources.redhat.com/ml/gdb-patches/2001-03/msg00568.html
No, that's doing it in variables, which is also the wrong place.
It's a property of the debug format, not of the variable.  Location 
expressions can also apply to types, etc, 
You shouldn't have to call "compute location dynamically" on a variable, 
ever.
There should be one way to get a location for a variable, it should just 
tell you the right answer, given the necessary info.
In reality, we should be asking the debug reader (or something above it 
that interfaces into the debug reader) where the heck it is.

Adding a compute_dynamic_location would make dynamic locations a special 
case.
In reality, if you want to do it on variables (which, as i've 
explained, is also the wrong place to keep this info), have a location 
function pointer, which gets set by the debug reader or whatever, to a 
function that can tell you where it is.

Right now we just keep adding possible location types, to try to match 
them up with what debug info can provide us, and shoehorn debug readers to 
fit into them.
This is silly.

We should have a debug info manager or something (this is not a job for 
the symtab, the symtab is used to tell you scopes/types/properties of 
symbols, not debug info), that given a symbol and the frame you want to 
evaluate it in, the address.

The debug info manager should also handle other things that we currently 
build structures for and let the symtab code manage, like psymtabs, 
reading things in, etc.
The symbol table could effectively be viewed as a cache of some set of 
debug info.
If it's not in the symbol table currently, we should ask the debug info 
manager, which would read in/do whatever is necessary to find the symbol.

The same way a virtual memory subsystem just asks for the page at a 
certain address, and lets the underlying backing method handle getting it 
for you.


Right now we are effectively trying to transfer knowledge that the debug 
info reader has to other parts of gdb when we read the debug info 
in, so that later it can try to figure out what the debug info reader 
really meant.  GDB shouldn't give a darn about how the debug info stores, 
or specifies evaluation of, locations of things.
We never care about the actual type of location, except to know how to 
evaluate it.
We map 128 things into 4, then try to determine which of the 128 we really 
meant by looking at it from different angles, lighting conditions, and 
the phase of the moon.
debug info readers know everything about how locations should be read 
and evaluated for their debug format.
That's their job.
It would actually remove and simplify a significant amount of code to just 
ask them directly (or, through some slightly higher level interface, like 
a debug info manager), and we'd get all the benefits of that debug format, 
too.

--Dan