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: Daniel Berlin <dan at dberlin dot org>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Jim Blandy <jimb at cygnus dot com>, 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 20:09:06 -0500 (EST)
- Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
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.
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,
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
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
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
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
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,