[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
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
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,
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).
Main Index |
Thread Index |