libelf

[Jason Thorpe <thorpej%shagadelic.org@localhost>]

You may have noticed that I checked in a port of FreeBSD's libelf the other 
day.  Let me outline what my plans are with libelf.

The idea is to get off of BFD-based manipulation of ELF images where possible 
(and where the tools are developed within the context of NetBSD, e.g. dbsym and 
mdsetimage).  This requires libelf to work in both native and host-tool 
environments.

The first step was the basic port of libelf -- FreeBSD has some differences in 
their ELF headers from ours.  This step is done, and libelf is available in 
native NetBSD builds.

The next step is to host-tool'ify libelf.  I have this done in my local tree, 
and will check it in today (even though nothing yet uses it).  I have built it 
on a Mac OS X host.

The next piece I'm working on is rewriting dbsym to use libelf rather than BFD. 
 As part of doing this, I discovered some changes were required in libelf to 
make this convenient.  I have that change in my local tree, and will commit it 
once dbsym is finished.  I may yet add some additional convenience functions to 
libelf (in particular, symbol lookup) that will be documented as NetBSD 
extensions.

Once dbsym is done, I'll tackle mdsetimage (it will be much easier :-).  paxctl 
would be on the list, as well (it doesn't use BFD, but it manipulates ELF 
images, and so is a candidate ... it would not hurt for this to be a host tool, 
either).

Long term, there is some interest in getting away from BFD-based ar(1), 
ranlib(1), etc.  Since we are firmly set in the ELF universe for the forseeable 
future, it seems reasonable to go this route (although the benefits are less 
clear so long as we still use BFD-based "other bits of the toolchain").  
Certainly, libelf could provide the basis of a non-BFD ELF toolchain, and that 
might be quite worthwhile to explore (and there is interest outside of NetBSD 
in this, as well).

-- thorpej