Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?

Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?

[Petr Sorfa]

Hi,

I'll be releasing several patches soon, starting with some DWARF III
support next week (I hope) and FORTRAN95 starting in March.
 
Just curious as to what timeline these patches will fit in (once they
are accepted.) The DWARF III I see making the 5.1.1 tree, but the
FORTRAN95 patches?

Petr
-- 
--------------------------------------------------------
Petr Sorfa                  Senior Software Engineer
Caldera
430 Mountain Ave.           http://www.caldera.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------

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

[Daniel Jacobowitz]

On Thu, Jan 17, 2002 at 05:03:14PM -0500, Petr Sorfa wrote:
> Hi,
> 
> I'll be releasing several patches soon, starting with some DWARF III
> support next week (I hope) and FORTRAN95 starting in March.
>  
> Just curious as to what timeline these patches will fit in (once they
> are accepted.) The DWARF III I see making the 5.1.1 tree, but the
> FORTRAN95 patches?

Nothing's going to make 5.1.1.  It's far too late; it'll be released in
a week, if I understood Andrew correctly.

Can you be more specific - what parts of DWARF3?  I've been working on
the dwarf2 reader in my spare time, and I'm willing to bet you'll
clobber all of those patches, so it would be nice if you fixed what I
was working on :P

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Berlin]

On Thu, 17 Jan 2002, Daniel Jacobowitz wrote:

> On Thu, Jan 17, 2002 at 05:03:14PM -0500, Petr Sorfa wrote:
> > Hi,
> > 
> > I'll be releasing several patches soon, starting with some DWARF III
> > support next week (I hope) and FORTRAN95 starting in March.
> >  
> > Just curious as to what timeline these patches will fit in (once they
> > are accepted.) The DWARF III I see making the 5.1.1 tree, but the
> > FORTRAN95 patches?
> 
> Nothing's going to make 5.1.1.  It's far too late; it'll be released in
> a week, if I understood Andrew correctly.
> 
> Can you be more specific - what parts of DWARF3?  I've been working on
> the dwarf2 reader in my spare time, and I'm willing to bet you'll
> clobber all of those patches, so it would be nice if you fixed what I
> was working on :P

I would imagine, based on reading some stuff on Intel's web site (that 
said they were having caldera modify gdb for them to support their 
compiler's debug output), that  he's adding the pieces needed to support 
Intel's C++ Compiler for Linux.

I have a list of what that outputs that gdb doesn't currently supports 
somewhere, but it might be easier for you to just look yourself, as it 
would take me a while to find it.
--Dan

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

[Daniel Jacobowitz]

On Thu, Jan 17, 2002 at 06:06:11PM -0500, Daniel Berlin wrote:
> On Thu, 17 Jan 2002, Daniel Jacobowitz wrote:
> 
> > On Thu, Jan 17, 2002 at 05:03:14PM -0500, Petr Sorfa wrote:
> > > Hi,
> > > 
> > > I'll be releasing several patches soon, starting with some DWARF III
> > > support next week (I hope) and FORTRAN95 starting in March.
> > >  
> > > Just curious as to what timeline these patches will fit in (once they
> > > are accepted.) The DWARF III I see making the 5.1.1 tree, but the
> > > FORTRAN95 patches?
> > 
> > Nothing's going to make 5.1.1.  It's far too late; it'll be released in
> > a week, if I understood Andrew correctly.
> > 
> > Can you be more specific - what parts of DWARF3?  I've been working on
> > the dwarf2 reader in my spare time, and I'm willing to bet you'll
> > clobber all of those patches, so it would be nice if you fixed what I
> > was working on :P
> 
> I would imagine, based on reading some stuff on Intel's web site (that 
> said they were having caldera modify gdb for them to support their 
> compiler's debug output), that  he's adding the pieces needed to support 
> Intel's C++ Compiler for Linux.
> 
> I have a list of what that outputs that gdb doesn't currently supports 
> somewhere, but it might be easier for you to just look yourself, as it 
> would take me a while to find it.

If you have a chance to find it, I'd appreciate it.  Otherwise I'll
wait for Petr; I'm swamped.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

[Petr Sorfa]

Hi,

The DWARF3 stuff which I plan to release soonist is the run-time
evaluation of DWARF3 DW_OP_* codes. In particular
DW_OP_push_object_address with DW_OP_* logical operators PLUS all the
existing DW_OP* functionality.

Basically the current implementation attaches DWARF info to struct type,
which gets evaluated at runtime when dealing with:

DW_AT_associated
DW_AT_allocated
DW_AT_data_location
DW_AT_stride
DW_AT_lower_bound
DW_AT_upper_bound
(some others may follow)

Most of this work is to support FORTRAN95 stuff, but should help other
languages that generate dynamic arrays with variable boundaries.

As I stated before, the current implementation just attaches the DWARF
data block to the struct type for simplicity. I guess there could be
some kind of internal representation of the functionality as well, but
some of the DW_OP_* sequences are pretty hairy so attaching the DWARF
data block and interpreting it on the fly seems OK to me.

It also highlights an overkill in the current GDB dwarf code which will
end up with three different stack/parsers/decoders of DW_OP_*
(dwarf2read.c:decode_locdesc, dwarf2cfi.c:execute_stack_op and my dwarf3
routine.) Granted there is different functionality for each so maybe
they should be kept separate.

Petr
> On Thu, Jan 17, 2002 at 06:06:11PM -0500, Daniel Berlin wrote:
> > On Thu, 17 Jan 2002, Daniel Jacobowitz wrote:
> >
> > > On Thu, Jan 17, 2002 at 05:03:14PM -0500, Petr Sorfa wrote:
> > > > Hi,
> > > >
> > > > I'll be releasing several patches soon, starting with some DWARF III
> > > > support next week (I hope) and FORTRAN95 starting in March.
> > > >
> > > > Just curious as to what timeline these patches will fit in (once they
> > > > are accepted.) The DWARF III I see making the 5.1.1 tree, but the
> > > > FORTRAN95 patches?
> > >
> > > Nothing's going to make 5.1.1.  It's far too late; it'll be released in
> > > a week, if I understood Andrew correctly.
> > >
> > > Can you be more specific - what parts of DWARF3?  I've been working on
> > > the dwarf2 reader in my spare time, and I'm willing to bet you'll
> > > clobber all of those patches, so it would be nice if you fixed what I
> > > was working on :P
> >
> > I would imagine, based on reading some stuff on Intel's web site (that
> > said they were having caldera modify gdb for them to support their
> > compiler's debug output), that  he's adding the pieces needed to support
> > Intel's C++ Compiler for Linux.
> >
> > I have a list of what that outputs that gdb doesn't currently supports
> > somewhere, but it might be easier for you to just look yourself, as it
> > would take me a while to find it.
> 
> If you have a chance to find it, I'd appreciate it.  Otherwise I'll
> wait for Petr; I'm swamped.
> 
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

-- 
--------------------------------------------------------
Petr Sorfa                  Senior Software Engineer
Caldera
430 Mountain Ave.           http://www.caldera.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------

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

[Daniel Berlin]

On Thu, 17 Jan 2002, Petr Sorfa wrote:

> Hi,
> 
> The DWARF3 stuff which I plan to release soonist is the run-time
> evaluation of DWARF3 DW_OP_* codes.

We had a discussion about how to do this a while ago.  I *hope* you didn't 
just make it dwarf2/3 specific, and add some kind of dwarf2 locexpr 
location type to the possible types of locations, and just keep dwarf2 
blocks around to evaluate.
This was deemed to be the wrong way to do it.
Instead, it was decided that it should be converted to a gdb specific 
language locexpr (which is, essentially, dwarf3 minus a few things that we 
don't need because we don't care about saving a few bytes here or there).
This is so we aren't tied down to the standard, and so people don't make 
assumptions about the format of the bytecode.

Don't look at meef, i thought, and think, that it is a horribly bad idea, 
as it adds another layer with no real reason for doing so.
I'm just telling you what the general consensus was.

> DW_OP_push_object_address with DW_OP_* logical operators PLUS all the
> existing DW_OP* functionality.
> 
> Basically the current implementation attaches DWARF info to struct type,
> which gets evaluated at runtime when dealing with:
> 
> DW_AT_associated
> DW_AT_allocated
> DW_AT_data_location
> DW_AT_stride
> DW_AT_lower_bound
> DW_AT_upper_bound
> (some others may follow)
> 
> Most of this work is to support FORTRAN95 stuff, but should help other
> languages that generate dynamic arrays with variable boundaries.
> 
> As I stated before, the current implementation just attaches the DWARF
> data block to the struct type for simplicity. I guess there could be
> some kind of internal representation of the functionality as well, but
> some of the DW_OP_* sequences are pretty hairy so attaching the DWARF
> data block and interpreting it on the fly seems OK to me.
This is exactly what i was told not to do.
In fact, I had code to do exactly what you say over a year ago, 
submitted it, and that is when the discussion started.
I have a patch to implement a gdb specific version of the dwarf2 bytecode 
(which was deemed the "right" solution) at 
http://sources.redhat.com/ml/gdb-patches/2001-06/msg00441.html.

--Dan

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

[Petr Sorfa]

Hi Daniel,

This is great news. Any idea if and when this support will be put in?

More comments below:

> > The DWARF3 stuff which I plan to release soonist is the run-time
> > evaluation of DWARF3 DW_OP_* codes.
> 
> We had a discussion about how to do this a while ago.  I *hope* you didn't
> just make it dwarf2/3 specific, and add some kind of dwarf2 locexpr
> location type to the possible types of locations, and just keep dwarf2
> blocks around to evaluate.
> This was deemed to be the wrong way to do it.
> Instead, it was decided that it should be converted to a gdb specific
> language locexpr (which is, essentially, dwarf3 minus a few things that we
> don't need because we don't care about saving a few bytes here or there).
> This is so we aren't tied down to the standard, and so people don't make
> assumptions about the format of the bytecode.
Nope that's fine.

> Don't look at meef, i thought, and think, that it is a horribly bad idea,
> as it adds another layer with no real reason for doing so.
> I'm just telling you what the general consensus was.
Well, my worry is that it isn't in the tree. 

> > DW_OP_push_object_address with DW_OP_* logical operators PLUS all the
> > existing DW_OP* functionality.
> >
> > Basically the current implementation attaches DWARF info to struct type,
> > which gets evaluated at runtime when dealing with:
> >
> > DW_AT_associated
> > DW_AT_allocated
> > DW_AT_data_location
> > DW_AT_stride
> > DW_AT_lower_bound
> > DW_AT_upper_bound
> > (some others may follow)
> >
> > Most of this work is to support FORTRAN95 stuff, but should help other
> > languages that generate dynamic arrays with variable boundaries.
> >
> > As I stated before, the current implementation just attaches the DWARF
> > data block to the struct type for simplicity. I guess there could be
> > some kind of internal representation of the functionality as well, but
> > some of the DW_OP_* sequences are pretty hairy so attaching the DWARF
> > data block and interpreting it on the fly seems OK to me.
> This is exactly what i was told not to do.
> In fact, I had code to do exactly what you say over a year ago,
> submitted it, and that is when the discussion started.
> I have a patch to implement a gdb specific version of the dwarf2 bytecode
> (which was deemed the "right" solution) at
> http://sources.redhat.com/ml/gdb-patches/2001-06/msg00441.html.
This looks good. I will need to be expanded to handle one or two things
(if necessary.) Now is there any way this is going to make it into the
tree soon? If I upgrade my Dwarf3 stuff to use your locexpr, will it be
sufficient motivation to commit the patch?

Petr
> 
> --Dan

-- 
--------------------------------------------------------
Petr Sorfa                  Senior Software Engineer
Caldera
430 Mountain Ave.           http://www.caldera.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------

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

[Petr Sorfa]

Hi Daniel,

A comment about the patch you mentioned before:
http://sources.redhat.com/ml/gdb-patches/2001-06/msg00441.html

I noticed that you put new entries into struct symbol of type locexpr.
I'm not too sure if that is the correct to place them. In my
understanding these location expressions need only be associated with
the type of a symbol rather than the symbol itself. This will remove
unnecessary replication of data and save the extra few bytes. Or am I
making to many assumptions here?

Petr
-- 
--------------------------------------------------------
Petr Sorfa                  Senior Software Engineer
Caldera
430 Mountain Ave.           http://www.caldera.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------

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

[Daniel Berlin]

On Fri, 18 Jan 2002, Petr Sorfa wrote:

> Hi Daniel,
> 
> A comment about the patch you mentioned before:
> http://sources.redhat.com/ml/gdb-patches/2001-06/msg00441.html
> 
> I noticed that you put new entries into struct symbol of type locexpr.
> I'm not too sure if that is the correct to place them. In my
> understanding these location expressions need only be associated with
> the type of a symbol rather than the symbol itself.
No, it describes the location of a symbol, not of a type.
Two symbols of the same type could be in different places (one in 
register, one in memory).
Think of location lists, too.
I could have two symbols of the same type in completely different places 
in memory and registers, at a given time (IE each in two different live 
ranges).

> This will remove
> unnecessary replication of data and save the extra few bytes. Or am I
> making to many assumptions here?
Also, part of the idea of using our own bytecode was being able to 
describe the location of complex things, such a vtable entry, in a 
portable way.
> 
> Petr
> 

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

[Petr Sorfa]

Hi Daniel,

> > A comment about the patch you mentioned before:
> > http://sources.redhat.com/ml/gdb-patches/2001-06/msg00441.html
> >
> > I noticed that you put new entries into struct symbol of type locexpr.
> > I'm not too sure if that is the correct to place them. In my
> > understanding these location expressions need only be associated with
> > the type of a symbol rather than the symbol itself.
> No, it describes the location of a symbol, not of a type.
> Two symbols of the same type could be in different places (one in
> register, one in memory).
> Think of location lists, too.
> I could have two symbols of the same type in completely different places
> in memory and registers, at a given time (IE each in two different live
> ranges).
Yes I agree for symbol location. However, other location expressions can
describe the lower and upper bounds of an array, or its stride,
associative and allocatable values. These are the ones that can be
located in the symbol's type. The main reason behind this, is that these
other locations are based off the location of the symbol.

Petr
> > This will remove
> > unnecessary replication of data and save the extra few bytes. Or am I
> > making to many assumptions here?
> Also, part of the idea of using our own bytecode was being able to
> describe the location of complex things, such a vtable entry, in a
> portable way.

-- 
--------------------------------------------------------
Petr Sorfa                  Senior Software Engineer
Caldera
430 Mountain Ave.           http://www.caldera.com
Murray Hill 07974
NJ, USA
--------------------------------------------------------
Disclaimer: All my comments are my own and nobody else's
----------------------------------------------------------

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

[Daniel Berlin]

On Fri, 18 Jan 2002, Petr Sorfa wrote:

> Hi Daniel,
> 
> > > A comment about the patch you mentioned before:
> > > http://sources.redhat.com/ml/gdb-patches/2001-06/msg00441.html
> > >
> > > I noticed that you put new entries into struct symbol of type locexpr.
> > > I'm not too sure if that is the correct to place them. In my
> > > understanding these location expressions need only be associated with
> > > the type of a symbol rather than the symbol itself.
> > No, it describes the location of a symbol, not of a type.
> > Two symbols of the same type could be in different places (one in
> > register, one in memory).
> > Think of location lists, too.
> > I could have two symbols of the same type in completely different places
> > in memory and registers, at a given time (IE each in two different live
> > ranges).
> Yes I agree for symbol location. However, other location expressions can
> describe the lower and upper bounds of an array, or its stride,
> associative and allocatable values. These are the ones that can be
> located in the symbol's type. The main reason behind this, is that these
> other locations are based off the location of the symbol.
Sure, i agree completely with this.

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

[Jim Blandy]

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.)

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

[Daniel Berlin]

On 23 Jan 2002, Jim Blandy wrote:

> 
> 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.
Nope, but that's okay.

> 
> 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.
Almost an exact duplicate, i removed some opcodes and whatnot that were 
pointless for us.

> 
> 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.

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

[Andrew Cagney]

> 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


Andrew

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

[Daniel Berlin]

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

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

[Daniel Jacobowitz]

On Wed, Jan 23, 2002 at 06:43:21PM -0500, Jim Blandy 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.
> 
> (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.)

Yes!  Yes yes yes yes yes yes yes!

(I like it.  A lot.  We should discuss details of this.)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Berlin]

On Wed, 23 Jan 2002, Daniel Jacobowitz wrote:

> On Wed, Jan 23, 2002 at 06:43:21PM -0500, Jim Blandy 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.
> > 
> > (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.)
> 
> Yes!  Yes yes yes yes yes yes yes!
> 
> (I like it.  A lot.  We should discuss details of this.)
I could swear we did once, but maybe it's all in my head.
It's one of the things i was working on before i stopped working on gdb, 
along with the type system rewrite (which is still on a branch, i never 
got around to creating a branch for the former).
No, i have the remnants of a tree where i changed symbol lookup and 
variable evaluation to go through the symbol readers through a high level 
interface to "debug info".
It doesn't compile though (I never finished converting the stabs reader it 
looks like), and it's based on gdb 5.0, so it's probably not worth tarring 
it all up and throwing it somewhere.

--Dan

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

[Jim Blandy]

Since it seems that GCC3 is now describing the location of virtual
base classes using complex Dwarf 2 expressions, I guess we should sort
this out quickly.  Whoever's idea it was... :)

At the moment, enum address_class does a number of different jobs:
- They distinguish functions, variables, and types (LOC_BLOCK,
  LOC_TYPEDEF, etc.)
- They distinguish arguments from local variables (compare LOC_REGISTER
  with LOC_REGPARM).
- They mark variables that have been optimized out
  (LOC_OPTIMIZED_OUT).

And maybe some other stuff?  I just grepped for all uses of
LOC_REGPARM and tried to figure out why the code cared.

In the end, I think we want to have:
- variables, members, and baseclasses able to indicate their locations
  using arbitrary functions provided by the debug readers,
- the other data disentangled from the location of the variable
  (although I guess "optimized out" really is the `nowhere' answer to
  the question, "Where is this variable now?"),
- all the extant address classes represented uniformly using
  function pointers
- enum address_class left representing only the kind of entry
  (var/func/typedef), and perhaps renamed.

But following the Canticle of St. Cagney, we need to do this in small,
incremental steps, so that at each point we have a GDB which works no
worse than it did before.

Here are the steps, as I see them:

- Get arbitrary Dwarf 2 location expressions working for variables.
  Add new members to enum address_class, LOC_COMPUTED and
  LOC_COMPUTED_ARG; symbols with this address class refer to some
  structure roughly like this:

    /* A structure of function pointers describing the location of a
       variable, structure member, or structure base class.

       These functions' BATON arguments are generic data pointers, holding
       whatever data the functions need --- the code which provides this
       structure also provides the actual contents of the baton, and
       decides its form.  However, there may be other rules about where
       the baton data must be allocated; whoever is pointing to this
       `struct location_funcs' object will know the rules.  For example,
       when a symbol S's location is LOC_COMPUTED, then
       SYMBOL_LOCATION_FUNCS(S) is pointing to a location_funcs structure,
       and SYMBOL_LOCATION_BATON(S) is the baton, which must be allocated
       on the same obstack as the symbol itself.  */

    struct location_funcs {

      /* Return the value of the variable described by BATON, relative to
         the stack frame FRAME.  If the variable has been optimized
         out, return zero.

         If `read_needs_frame (BATON)' is zero, then FRAME may be
         zero.  */
      struct value *(*read_variable) (void *baton, struct frame_info *frame);

      /* Return true if we need a frame to find the value of the object
         described by BATON.  */
      int (*read_needs_frame) (void *baton);

      /* Write to STREAM a natural-language description of the location of
         the object described by BATON.  */
      int (*describe_location) (void *baton, struct ui_file *stream);

      /* Tracepoint support.
         Append bytecodes to the tracepoint agent expression AX that push
         the address of the object described by BATON.  Set VALUE
         appropriately.  Note --- for objects in registers, this needn't
         emit any code; as long as it sets VALUE properly, then the caller
         will generate the right code in the process of treating this as
         an lvalue or rvalue.  */
      void (*tracepoint_var_ref) (void *baton,
                                  struct agent_expr *ax,
                                  struct axs_value *value);

    };

  So dwarf2expr.c (or whatever) will define one of these structures
  for location expressions, and some structure for the batons, and
  dwarf2read.c will build symbols that refer to them.  We could add
  support for location lists, too, without touching the rest of GDB.

  All code that uses `enum address_class' now will need to be
  updated.  There will be some changes needed to the generic symbol
  building functions that the debug readers use.

  (I think the Dwarf 2 location expression interpreter should be in its
  own file, since it is going to depend on a lot of stuff that the
  normal symbol reader really shouldn't care about --- stack frames,
  actual register values, etc.)

  We'll need another function like `read_variable' for finding virtual
  base classes; I don't know what its arguments should be.

- Same for C++ virtual base classes.

- Same for individual members.  (Where is this needed?  Don't we just
  need it for base classes?)

- Move the "argument vs. local var" information into a separate field
  of `struct symbol' and `struct partial_symbol'.  LOC_COMPUTED and
  LOC_COMPUTED_ARG become the same thing.

- Gradually write location_funcs structures for the other address
  classes (offset from FP, etc.).  Put the widely useful ones (offset
  from FP) someplace generic; put others in the symbol readers that
  generate them.

- Once `enum address_class' is left containing only LOC_UNDEF,
  LOC_CONST, LOC_BLOCK, LOC_LABEL, LOC_TYPEDEF, rename it to something
  more appropriate.  :)

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

[Daniel Berlin]

On 1 Feb 2002, Jim Blandy wrote:

> 
> Since it seems that GCC3 is now describing the location of virtual
> base classes using complex Dwarf 2 expressions, I guess we should sort
> this out quickly.  Whoever's idea it was... :)
> 
> At the moment, enum address_class does a number of different jobs:
> - They distinguish functions, variables, and types (LOC_BLOCK,
>   LOC_TYPEDEF, etc.)
> - They distinguish arguments from local variables (compare LOC_REGISTER
>   with LOC_REGPARM).
> - They mark variables that have been optimized out
>   (LOC_OPTIMIZED_OUT).
> 
> And maybe some other stuff?  I just grepped for all uses of
> LOC_REGPARM and tried to figure out why the code cared.
> 
> In the end, I think we want to have:
> - variables, members, and baseclasses able to indicate their locations
>   using arbitrary functions provided by the debug readers,
> - the other data disentangled from the location of the variable
>   (although I guess "optimized out" really is the `nowhere' answer to
>   the question, "Where is this variable now?"),
> - all the extant address classes represented uniformly using
>   function pointers
> - enum address_class left representing only the kind of entry
>   (var/func/typedef), and perhaps renamed.
> 
> But following the Canticle of St. Cagney, we need to do this in small,
> incremental steps, so that at each point we have a GDB which works no
> worse than it did before.
> 
> Here are the steps, as I see them:
> 
> - Get arbitrary Dwarf 2 location expressions working for variables.
>   Add new members to enum address_class, LOC_COMPUTED and
>   LOC_COMPUTED_ARG; symbols with this address class refer to some
>   structure roughly like this:
> 
>     /* A structure of function pointers describing the location of a
>        variable, structure member, or structure base class.
> 
>        These functions' BATON arguments are generic data pointers, holding
>        whatever data the functions need --- the code which provides this
>        structure also provides the actual contents of the baton, and
>        decides its form.  However, there may be other rules about where
>        the baton data must be allocated; whoever is pointing to this
>        `struct location_funcs' object will know the rules.  For example,
>        when a symbol S's location is LOC_COMPUTED, then
>        SYMBOL_LOCATION_FUNCS(S) is pointing to a location_funcs structure,
>        and SYMBOL_LOCATION_BATON(S) is the baton, which must be allocated
>        on the same obstack as the symbol itself.  */
> 
>     struct location_funcs {
> 
>       /* Return the value of the variable described by BATON, relative to
>          the stack frame FRAME.  If the variable has been optimized
>          out, return zero.
> 
>          If `read_needs_frame (BATON)' is zero, then FRAME may be
>          zero.  */
>       
struct value *(*read_variable) (void *baton, struct frame_info *frame);
> 
>       /* Return true if we need a frame to find the value of the object
>          described by BATON.  */
>       int (*read_needs_frame) (void *baton);
> 
>       /* Write to STREAM a natural-language description of the location of
>          the object described by BATON.  */
>       int (*describe_location) (void *baton, struct ui_file *stream);

I assume natural language is a codeword for "meant for user only, don't 
try to parse it"?

> 
>       /* Tracepoint support.
>          Append bytecodes to the tracepoint agent expression AX that push
>          the address of the object described by BATON.  Set VALUE
>          appropriately.  Note --- for objects in registers, this needn't
>          emit any code; as long as it sets VALUE properly, then the caller
>          will generate the right code in the process of treating this as
>          an lvalue or rvalue.  */

Is this always possible without a current address?
IE can the agent bytecode support the fact that for location lists, we 
need to know where we are before we can tell you where the variable is.
One could encode this as a bunch of if's and comparisons if the agent 
bytecode supports them, i guess.

>       void (*tracepoint_var_ref) (void *baton,
>                                   struct agent_expr *ax,
>                                   struct axs_value *value);
> 
>     };
> 
>   So dwarf2expr.c (or whatever) will define one of these structures
>   for location expressions, and some structure for the batons, and
>   dwarf2read.c will build symbols that refer to them.  We could add
>   support for location lists, too, without touching the rest of GDB.
> 
>   All code that uses `enum address_class' now will need to be
>   updated.  There will be some changes needed to the generic symbol
>   building functions that the debug readers use.
> 
>   (I think the Dwarf 2 location expression interpreter should be in its
>   own file, since it is going to depend on a lot of stuff that the
>   normal symbol reader really shouldn't care about --- stack frames,
>   actual register values, etc.)
> 
>   We'll need another function like `read_variable' for finding virtual
>   base classes; I don't know what its arguments should be.
> 
> - Same for C++ virtual base classes.
> 
> - Same for individual members.  (Where is this needed?  Don't we just
>   need it for base classes?)
> 
> - Move the "argument vs. local var" information into a separate field
>   of `struct symbol' and `struct partial_symbol'.  LOC_COMPUTED and
>   LOC_COMPUTED_ARG become the same thing.
> 
> - Gradually write location_funcs structures for the other address
>   classes (offset from FP, etc.).  Put the widely useful ones (offset
>   from FP) someplace generic; put others in the symbol readers that
>   generate them.


Here's a question to think about as we move towards that:
Where should the cache be?

If you are using oft-computed expressions, we should be able to cache them 
if the information they depend on hasn't changed.

Should each thing that implements the functions above handle caching 
internally, or should we put it one level above, and add functions to make 
generic queries like "is this location going to change if the x 
register changes".

Assuming the queries are cheap, you could simply walk the changed 
values in the frame, ask if if any matter, and if not, you don't need 
to redo the calculation/value.

 > > - Once `enum 
address_class' is left containing only LOC_UNDEF,
>   LOC_CONST, LOC_BLOCK, LOC_LABEL, LOC_TYPEDEF, rename it to something
>   more appropriate.  :)
> 

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

[Andrew Cagney]

> 
> 
> Here's a question to think about as we move towards that:
> Where should the cache be?
> 
> If you are using oft-computed expressions, we should be able to cache them 
> if the information they depend on hasn't changed.
> 
> Should each thing that implements the functions above handle caching 
> internally, or should we put it one level above, and add functions to make 
> generic queries like "is this location going to change if the x 
> register changes".
> 
> Assuming the queries are cheap, you could simply walk the changed 
> values in the frame, ask if if any matter, and if not, you don't need 
> to redo the calculation/value.


Relatively speaking I'd expect it to be cheap.

The most common case of something changing is when the target is 
resumed.  For this case, GDB has to invalidate everything and start 
again from scratch.  Hence, this is the case GDB needs to have working 
fast.  Initially, at least, register and memory writes can just be 
treated like target resumes - target-changd.

Supporting this is varobj (well what I understand of it) Varobj tracks 
variables identifying those that changed.  It then provides a refresh 
list to the UI (Insight or MI).  While the computation necessary to 
identify changed variables is singificant, it is nothing when compared 
to the overhead of refreshing a variable's value on the screen.  By 
avoiding unnecessary refreshes, performance is significantly improved.

The other thing is that GDB has plenty of easier fixes when it comes to 
caching: not flushing the cache when switching threads; pre-fetching 
memory; ....

Anyway, as they say, get it working, then get it working fast;  A slow 
program shipped today is still quicker than a fast program shipped 
tomorrow; ... :-^

--

Jim,

to throw a question in here.  Where does this overall change leave 
$frame?  I'm suspecting that the existing frame code ends up being 
pushed sideways and down covered by a new layer that lets you get at the 
above.


enjoy,
Andrew

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

[Jim Blandy]

Daniel Berlin <dan@dberlin.org> writes:
> >       /* Write to STREAM a natural-language description of the location of
> >          the object described by BATON.  */
> >       int (*describe_location) (void *baton, struct ui_file *stream);
> 
> I assume natural language is a codeword for "meant for user only, don't 
> try to parse it"?

Well, that function is just there for the `info address' command:

    (gdb) info addr argc
    Symbol "argc" is an argument at offset 8.
    (gdb) 

So its job is to be comprehensible to the user, and accurate enough to
be useful to people hacking on GDB; it doesn't have many technical
constraints on what it says.


> >       /* Tracepoint support.
> >          Append bytecodes to the tracepoint agent expression AX that push
> >          the address of the object described by BATON.  Set VALUE
> >          appropriately.  Note --- for objects in registers, this needn't
> >          emit any code; as long as it sets VALUE properly, then the caller
> >          will generate the right code in the process of treating this as
> >          an lvalue or rvalue.  */
> 
> Is this always possible without a current address?
> IE can the agent bytecode support the fact that for location lists, we 
> need to know where we are before we can tell you where the variable is.
> One could encode this as a bunch of if's and comparisons if the agent 
> bytecode supports them, i guess.

Oh, you're right --- yes, you need a sal in order to decide what
bytecode to emit.  A tracepoint's bytecode gets run when we hit a
tracepoint, so GDB can generate bytecode specific to that PC.

> >       void (*tracepoint_var_ref) (void *baton,
> >                                   struct agent_expr *ax,
> >                                   struct axs_value *value);

So that should be:

      /* Tracepoint support.
         Append bytecodes to the tracepoint agent expression AX that
         push the address of the object described by BATON, at the
         point in the code given by tracepoint_pos.  Set VALUE
         appropriately.  Note --- for objects in registers, this
         needn't emit any code; as long as it sets VALUE properly,
         then the caller will generate the right code in the process
         of treating this as an lvalue or rvalue.  */
       void (*tracepoint_var_ref) (void *baton,
                                   struct symtabs_and_lines *tracepoint_pos,
                                   struct agent_expr *ax,
                                   struct axs_value *value);

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

[Andrew Cagney]

> But following the Canticle of St. Cagney, we need to do this in small,
> incremental steps, so that at each point we have a GDB which works no
> worse than it did before.


:-)

The word shouldn't fits in there somewhere.  It shouldn't be any worse 
than it was before.  There is always short term instability but GDB 
still continues to work, mostly :-)

Andrew

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

[Andrew Cagney]

> On Thu, Jan 17, 2002 at 05:03:14PM -0500, Petr Sorfa wrote:
> 
>> Hi,
>> 
>> I'll be releasing several patches soon, starting with some DWARF III
>> support next week (I hope) and FORTRAN95 starting in March.
>> > Just curious as to what timeline these patches will fit in (once they
>> are accepted.) The DWARF III I see making the 5.1.1 tree, but the
>> FORTRAN95 patches?
> 
> 
> Nothing's going to make 5.1.1.  It's far too late; it'll be released in
> a week, if I understood Andrew correctly.


Yes.

The same would apply to 5.2.  Rather than focusing on timelines and 
trying to tie functionality to specific releases, can I suggest instead 
just concentrating on getting the best possible code into the trunk.

Andrew