From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8883 invoked by alias); 18 Jan 2002 00:12:15 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8844 invoked from network); 18 Jan 2002 00:12:13 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 18 Jan 2002 00:12:13 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g0I0AZn21321; Thu, 17 Jan 2002 19:10:35 -0500 Date: Thu, 17 Jan 2002 16:12:00 -0000 From: Daniel Berlin To: Petr Sorfa cc: Daniel Jacobowitz , Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2? In-Reply-To: <3C4760B2.53889E14@caldera.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-01/txt/msg00201.txt.bz2 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