This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
- From: Petr Sorfa <petrs at caldera dot com>
- To: Daniel Berlin <dan at dberlin dot org>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, gdb at sources dot redhat dot com
- Date: Fri, 18 Jan 2002 10:02:01 -0500
- Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
- Organization: Caldera
- References: <Pine.LNX.4.44.0201171900010.21196-100000@dberlin.org>
- Reply-to: 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
----------------------------------------------------------