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 of CFI
On Tue, Apr 02, 2002 at 09:55:06PM -0500, Daniel Berlin wrote:
> 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.
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