Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions

[Daniel Berlin <dan at www dot cgsoftware dot com>]

On Fri, 6 Apr 2001, Andrew Cagney wrote:

> Daniel Berlin wrote:
> >
> > Andrew Cagney <ac131313@cygnus.com> writes:
> >
> > > > So the code doesn't belong in dwarf2read.c.  dwarf2read.c is a symbol
> > > > reader. dwarf2 location expressions are a way of describing variable
> > > > locations.  The other code to process the current gdb address
> > > > classes/locations is in findvar.c, so that's where i put it.
> > >
> > > No.
> > >
> > >     if (frame == NULL)
> > >       frame = selected_frame;
> > > !   if (SYMBOL_DWARF2_LOC (var) != NULL)
> > > !     return evaluate_dwarf2_locdesc (var, frame, (struct dwarf_block *)
>
> Some code, somewhere must be setting SYMBOL_DWARF2_LOC (var).  At a
> guess that code is either in dwarf2read.c or in a file using information
> obtained from dwarf2read.c.

Correct. It's currently dwarf2read.c
But it doesn't actually have to be, as I said, I could easily convert
stabsread.c to make location expressions and set SYMBOL_DWARF2_LOC, there
just wouldn't be much point, because we can already handle everything
STABS throws at us.

 >
> If SYMBOL_DWARF2_LOC() was replaced by a more generic method then, I'd
> expect that method to live in dwarf2read.c since it would be
> dwarf2read.c creating a type that contained that method.

I'll probably rename it to SYMBOL_LOCATION_LIST, and replace DWARF2_LOC
everywhere with LOCATION_LIST. This way, people realize the only reason
it's called a dwarf2 location list is because it, and the opcodes, happens
to be descriobed in the dwarf2 spec.  Anything that wants to, could create them, it relies
on nothing specific to dwarf2.
Other things use dwarf2 location lists to describe locations.  It's just a
robust way of describing the location of variables.
In fact, if it's not too difficult, i might change one of the other debug
info readers to use them for symbol locations, just to prove the point (I
wouldn't expect the patch to be accepted, of cuorse).

l >
> > > For this starts to make sense, I suspect it needs to be given some
> > > additional context - namely where in dwarf2read.c things are also going
> > > to be changed.
> >
> > Make sense?
> > In what way?
>
> It might help explain how this patch ties in to the rest of GDB.
>
As I said, this patch is completely independent of anything that goes on
in the dwarf2 reader. It just defines another way of describing the
location of a variable, a way that happens to be explained in the dwarf2
specification.  There is absolutely nothing dwarf2 specific about it, or
anything that even ties it to dwarf2 as a debugging format.  DWARF2 just
happens to use it as it's way of describing locations, much the same way
g++ exception handling happens to use it as it's way of describing
locations.

That said, the new dwarf2 reader will use location lists, rather
than try to convert a location list into one of the other ways to
describe the location of symbols.  It will also use location lists in
another place to describe the location of a register at a given PC (IE in
the virtaul frame unwinding stuff i'm working on as well)

 Here's the history and where everything  stands:
As you may or may not know, in order to do dwarf2 duplicate
elimination, it's necessary to comdat dwarf2 DIEs.  So, unlike before, you
have DWARF2 DIEs that may refer to DIEs in another DWARF2 compilation
unit.


The current dwar4f2 reade, of course, uses static and global structures
everywhere, and expects to be able to process a single compilation unit at
a time, without having to know anything about *any othre* compilation
units.

Which of course, won't work when you have references to dies in other
units (IE we may have a DIE representing a variable, and the type
attribute of that DIE may be pointing to a DIE in a  different compilation
unit).

These assumptions are so pervasive through dwarf2read that it essentially
required changing, well, everything (the current diff is 85k).  Since it
required so much work to do this, it made sense to put the time in to take
advantage of the other things dwarf2 provides us, that we don't currently
take advantage of, such as the ability to use the virtual frame info to
get at things in the frame/saved registers, rather than rely on target
specific scanning code and such.

the patch i submitted was a first pass at the non-dwarf2 specific parts of
this kind of support.

It's one of those "I wish i had given stuff a different name now" type of
things, since it just seems to confuse people.


Mentioning the virtaul frame info reminds me.  Currently, i have patched
generic_get_saved_register to use the virtual frame info to find a
register, if it can, in preference to the target specific code.  Is
this the right place to do this?  This is where it has the target
specific code fill in the saved registers it knows about, and i'm
just doing the same with the virtual frame info, rather than target
specific code.  It simply calls a function that is impemented in
dwarf2eval.c that does all the same dirty work FRAME_INIT_SAVED_REGS does.

Modifying FRAME_INIT_SAVED_REGS for every platform tidn't seem to be the
right thing to do, since, as I said, the same procedure works on all
platforms, since the target dependent stuff is on the gcc side.
  > 	 enjoy, > 		 Andrew >