From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23339 invoked by alias); 3 Apr 2002 02:55:09 -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 23315 invoked from network); 3 Apr 2002 02:55:07 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 3 Apr 2002 02:55:07 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g332t6m07704; Tue, 2 Apr 2002 21:55:06 -0500 Date: Tue, 02 Apr 2002 18:55:00 -0000 From: Daniel Berlin To: Jim Blandy cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg00054.txt.bz2 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. 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. Of course, the hilarious part of all this work is that Intel did it once already, including writing what appears to be their own compatible libdwarf (At least, I don't have much older versions of libdwarf, but the copyrights aren't in the intel version, but all the interfaces are the same. It also supports some things libdwarf still doesn't, which makes me think it was done separately), and rewriting dwarf2read.c to use it. 3 years ago, by the timestamps (they are all timestamp'd at March 8, 1999). Hilarious in that it makes me want to cry, of course. --Dan