On Wed, Jan 8, 2020 at 3:48 PM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
