From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32030 invoked by alias); 18 Jan 2002 15:08:26 -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 31987 invoked from network); 18 Jan 2002 15:08:24 -0000 Received: from unknown (HELO nimbus.nj.caldera.com) (132.147.103.56) by sources.redhat.com with SMTP; 18 Jan 2002 15:08:24 -0000 Received: from caldera.com (IDENT:petrs@tetsuo [132.147.135.116]) by nimbus.nj.caldera.com (8.10.1/UW7.1.1-NSCd) with ESMTP id g0IF7Ka18447; Fri, 18 Jan 2002 10:07:20 -0500 (EST) Message-ID: <3C4838E9.68F94D8@caldera.com> Date: Fri, 18 Jan 2002 07:08:00 -0000 From: Petr Sorfa Reply-To: petrs@caldera.com Organization: Caldera X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Berlin CC: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00211.txt.bz2 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 ----------------------------------------------------------