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

[Daniel Berlin <dan@dberlin.org>]

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