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

[enh]

On Wed, Jan 8, 2020 at 3:48 PM Rob Landley <rob at landley.net> wrote:
>
>
>
> 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)

i see nm is on that list, so maybe -- even though i greatly prefer
readelf -- i should make the readelf parser support nm too...

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

meh, don't worry about it... readelf isn't used in the AOSP build, and
i'm happy with folks using it out of pending/ for interactive dicking
around. (whereas if you're happy to let getopt(1) depend on
getopt(3)/getopt_long(3)... :-) )

> Rob