This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 1 Apr 2002, Jim Blandy wrote:

> 
> 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. 


> 
> Daniel Berlin <dan@dberlin.org> writes:
> > In particular, you just need some initial value, or no initial value, not 
> > a push object address value/other types of things that may get pushed to 
> > the front.
> 
> Well, DW_AT_data_member_location expressions want the base address of
> the innermost enclosing structure on the stack, whereas
> DW_AT_use_location expressions want the pointer-to-member value and
> the object's base address on the stack.  So we've got situations which
> need zero, one, and two values on the stack.  So it seems like the
> basic interface should let people push as much as they want.
> 
> > Also, why would something need our evaluator if they already knew how to 
> > read DIE's at a given offset? It's very likely they can also evaluate 
> > expressions if they can read DWARF2 at all.
> 
> Well, to share code, I guess.  They'd toss their interpreter to use
> ours, and spread the maintenance job around. 
I sincerely doubt they would do this.
They gain nothing by conversion, but become dependent on us.
:)


> I have no clients in
> mind, just general principle.  When we've got something whose behavior
> is well-specified with no reference to GDB, it just seems like good
> practice to produce an implementation that, likewise, is independent
> of GDB.
> 
> > If, however, this is what GDB people want it to look like, i'll happily 
> > implement it.  It's not like it'll be that much more work for me.
> 
> I'd approve it.  :)
> 


I'll do it, i'm just concerned we are thinking of duplicating a library 
for the sake of duplicating a library.
:)
--Dan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]