PATCH: new DWARF-2 reader

[Casey Marshall]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> Casey Marshall writes:
>> >>>>> "Casey" == Casey Marshall <csm@gnu.org> writes:
>> 
>> Revised again, fixing a few remaining problems with the implementation
>> (the DWARF-2 spec is really hard to interpret! I hope now that it is
>> accurate) and fit it into the Throwable machinery.
>> 
>> 2005-03-26  Casey Marshall  <csm@gnu.org>
>> 
>> * gnu/gcj/runtime/NameFinder.java (use_dwarf2): new constant.
>> (<clinit>): new method, fill in boolean config variables with
>> GetPropertyAction.
>> (dwarf2finders): new field.
>> (lookup): try DWARF-2 finder before addr2line.
>> * gnu/gcj/runtime/Dwarf2NameFinder.java: new file.
>> * gnu/gcj/runtime/SectionFinderELF32.java: new file.
>> * gnu/gcj/runtime/SectionFinderUnknown.java: new file.
>> * Makefile.am (built_java_source_files): add
>> 'SectionFinder.java'
>> (ordinary_java_source_files): add 'Dwarf2NameFinder.java'
>> (configure.ac): link the appropriate SectionFinder class to
>> SectionFinder.java

Andrew> Thanks.

Andrew> I think we should go with this, at least for the time being.
Andrew> However, at a minimum, it needs first to be tested on 32- and
Andrew> 64-bit systems, big- and little-endian.  We should be able to
Andrew> co-operate to do this.

64 bit won't work yet, simply because there isn't any code yet to read
64-bit ELF files. But adding an implementation of that is
straightforward.

Andrew> There is a rival proposal that we use elfutils to do the
Andrew> reading.  At the present time elfutils is licensed under the
Andrew> OSL (Open Software License) and not assigned to the FSF.  And,
Andrew> acording to http://people.redhat.com/drepper/, the DWARF
Andrew> library is currently being reworked.

Wouldn't that limit the usefulness of this to ELF binaries? I
understand that there are other executable formats that GCJ targets
(MachO on Darwin being one, but it's unclear if that supports DWARF
debug info or not).

Andrew> In the long term I don't think it makes a huge amount of sense
Andrew> for libgcj to have a private DWARF reader -- it'll have its
Andrew> own bugs, and will need to be maintained.  However, it is a
Andrew> real advantage for us to have this code now, so I think it
Andrew> should go in.

Part of the reason why I worked on this was because the available
alternatives (bfd, pretty much) did not have compatible licenses. But
I do think that having this code as a part of libgcj has its
advantages; not the least of which being that Java-specific
optimizations (perhaps by noting where the compilation units for each
method are in that section, as a part of the Class info, to speed up
the line number search).

I also entertained the idea of turning this code into a more generic
library, akin to bfd.

Thanks!

-- 
Casey Marshall || csm@gnu.org