From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17673 invoked by alias); 3 Apr 2002 05:02:43 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17666 invoked from network); 3 Apr 2002 05:02:40 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 3 Apr 2002 05:02:40 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16scuw-0008Bf-00; Wed, 03 Apr 2002 00:02:42 -0500 Date: Tue, 02 Apr 2002 21:02:00 -0000 From: Daniel Jacobowitz To: Daniel Berlin Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI Message-ID: <20020403000242.A31097@nevyn.them.org> Mail-Followup-To: Daniel Berlin , Jim Blandy , gdb-patches@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00056.txt.bz2 On Tue, Apr 02, 2002 at 09:55:06PM -0500, Daniel Berlin wrote: > On 2 Apr 2002, Jim Blandy wrote: > > > > > Daniel Berlin writes: > > > > It may well be overengineered. A libdwarf is indeed what I had in > > > > mind; I thought it might be nice to start putting together the pieces > > > > for it. > > > > > > 1. The existing libdwarf is now LGPL'd, so it would be easier to just use > > > that, if you wanted a dwarf reader (in fact, this is what the majority of > > > consumers do use). > > > It would make more sense to just implement what's missing (it contains no > > > macro info reading, and no generic location expression support). > > > 2. Ulrich Drepper has the beginnings of a GPL'd libdwarf already that > > > works pretty well. > > > > Does Uli's libdwarf have an expression evaluator? > > > > > I'll do it, i'm just concerned we are thinking of duplicating a library > > > for the sake of duplicating a library. > > > :) > > > > I didn't know about the existing libdwarf, or Uli's. It would be nice > > to start using those, if we can. And I'll bet if the interfaces are > > troublesome for GDB, then Uli would be happy to change it. > > > I'll tell you what. > Since I don't have Uli's handy anymore, and I know the interface was > exactly that of libdwarf's, i'm willing to write a GPL'd library with the > same interface. > It likely won't take more than a weekend to give you enough to replace > what the dwarf2 reader currently does. That'd be cool. > I won't change the interface, however. The libdwarf interface is sensible, > and easy to use. The main reason i won't change it, though, is that it > hides all the things that we take for granted or do wrong in the current > dwarf2 reader, and thus, causes most of the pain of modifying it. > > Specifically, no internal access to any structure is allowed, you just > pass around opaque contexts. No globals, either. The concept's OK. There's some places where I think we'll need a little more; for instance, a hook to provide the contents of Dwarf sections instead of it reading them from the file. (Why, you ask? Because sometimes we need to apply relocations to them. I really doubt that's in the scope of a DWARF-2 reader.) I suppose for the convenience of having a good DWARF-2 reader, I can move the bad-compiler line-number-fixup stuff outside of the reader; that shouldn't be too hard to do, and would be much cleaner. Those are the only two major hacks I can think of at the moment that would really be beyond scope of the reader. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer