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

[Petr Sorfa <petrs at caldera dot com>]

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