This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside ofCFI
- From: Daniel Berlin <dan at dberlin dot org>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 2 Apr 2002 21:55:06 -0500 (EST)
- Subject: Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside ofCFI
On 2 Apr 2002, Jim Blandy wrote:
>
> Daniel Berlin <dan@dberlin.org> 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