[Toybox] [PATCH] Implement readelf(1).

[Rob Landley]

On 1/7/20 7:59 PM, enh via Toybox wrote:
> Basic readelf(1) implementation, with output close enough to the binutils
> version to be usable with scripts that expect the binutils version. This
> started as an implementation of nm(1) until I realized that I almost always
> want readelf instead, and that you actually have to do much of the work
> needed for readelf just to implement nm. Arguably nm (being part of POSIX)
> belongs in toybox while readelf doesn't. An argument could also be made that
> neither really belongs in toybox, belonging in a separate set of development
> tools (such as binutils or the LLVM binutils).

I maintained my own tinycc fork for 3 years (https://landley.net/code/tinycc and
http://landley.net/hg/qcc/file/tip/todo/TODO.old) because I wanted to turn it
into a multiplexed command that had cc, ld, nm, strip, and so on. (see
https://elinux.org/CELF_Project_Proposal/Combine_tcg_with_tcc and
http://landley.net/hg/qcc/file/tip/todo/commands.txt)

Alas, I was busy with other stuff and nobody ever wanted to fund it and it came
third after getting aboriginal linux to build itself under itself (done) and
getting toybox to fully replace busybox (about 3/4 done now).

Hijacking Android into a self-hosting development environment to complete the
PC's transition into big iron normal people don't have in their house (like the
mainframe and minicomputer before it) is just ONE of my insane overreaches. :)

That said, since I didn't wind up having cycles to throw at
https://landley.net/code/qcc I've been planning to add make to toybox instead of
having it be one of the qcc multiplexer commands. (The main reason a
tinycc-style cc doesn't belong in toybox is it's got architecture-specific
output for an unbounded number of architectures. Then again that isn't stopping
strace or file. If I can make it smaller than toysh...)

Oh, the "cfront" problem to compile c++ got solved by
https://github.com/JuliaComputing/llvm-cbe so you can bootstrap llvm from a pure
C compiler in an architecture-independent manner now. Just compile it to C on
some other platform, and feed that in as the source you build under tinycc on
your airlocked new system. Auditing LLVM for "trusting trust" and binary
reproducibility issues is left as an exercise for the reader, but a diverse
double-compiling airlock _is_ possible. Working on it, have been for years. Sad
the rest of the world doesn't care, but oh well...)

(You read https://dwheeler.com/trusting-trust/wheelerd-trust.pdf right?)

> Doesn't support most of the architecture-specific stuff, most notably
> relocations, but is aware of things like ARM exidx sections and the common
> register state notes in core dumps for the "big four" architectures: arm,
> arm64, x86, and x86-64.

Having a todo list doesn't stop things from being promoted.

Applied. I'll try to review for promotion when I get a chance, but I'm always
busy in Japan...

Rob