From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14662 invoked by alias); 24 Jan 2002 00:18:46 -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 14614 invoked from network); 24 Jan 2002 00:18:43 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 24 Jan 2002 00:18:43 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g0O0Gxn20537; Wed, 23 Jan 2002 19:16:59 -0500 Date: Wed, 23 Jan 2002 16:18:00 -0000 From: Daniel Berlin To: Jim Blandy cc: Petr Sorfa , Daniel Jacobowitz , Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-01/txt/msg00274.txt.bz2 On 23 Jan 2002, Jim Blandy wrote: > > Daniel B. submitted patches to allow GDB to handle arbitrary Dwarf 2 > location expressions. However, the initial patch simply extended the > functions that care about symbol locations (like read_var_value, for > example) with another case that evaluated a Dwarf 2 location > expression. > > However, I felt it was important to keep the core of GDB independent > of any particular debug representation. Daniel B. was very > accommodating, and revised the patch to introduce a new, "neutral" > expression representation, and translate Dwarf 2 location expressions > into that form. I think I had some concerns about the exact way it > had been done, but I don't remember --- in general it was fine. I > don't know what happened to the patch, but I don't think it ever got > approved. Nope, but that's okay. > > But while I feel pretty good about the "keep GDB's core independent of > the debug formats" rule, I felt pretty bad about introducing what > amounted to an exact duplicate of the Dwarf 2 location list > interpreter, with the constants renamed. Surely that wasn't > the right thing. Almost an exact duplicate, i removed some opcodes and whatnot that were pointless for us. > > Another approach occurred to me just now that I wish I had thought of > when Daniel B.'s patch first appeared. If the core of GDB could > define a structure of functions (resembling `struct cp_abi_ops', > `struct target_ops', etc.) that allowed a debug reader to provide its > own set of functions for finding variables, describing their locations > in English, and everything else we do with `enum address_class' now, > then that would make it easy and clean to use straight Dwarf 2 > location expressions, without any translation into an allegedly > "neutral" representation, and without contaminating the core of GDB. I think i mentioned this a few times as the cleanest way to also be able to get rid of psymtabs for dwarf2, and use .debug_aranges/pubnames/etc. It would let you make stabs use psymtabs internally, and make dwarf2 less memory intensive and faster to load.