Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI

[Daniel Jacobowitz <drow@mvista.com>]

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