[Toybox] [PATCH] riscv: decode ELF header e_flags.

[enh]

do you want a patch with the arm32 flags too?

On Mon, Oct 30, 2023 at 4:58 PM enh <enh at google.com> wrote:
>
> On Mon, Oct 30, 2023 at 4:36 PM Rob Landley <rob at landley.net> wrote:
> >
> > On 10/30/23 17:47, enh wrote:
> > > On Mon, Oct 30, 2023 at 3:29 PM Rob Landley <rob at landley.net> wrote:
> > >>
> > >> On 10/29/23 13:05, enh via Toybox wrote:
> > >> > ---
> > >> >  lib/lib.c            | 13 +++++++++++++
> > >> >  lib/lib.h            |  1 +
> > >> >  toys/other/readelf.c |  3 ++-
> > >> >  toys/posix/file.c    |  5 +++--
> > >> >  4 files changed, 19 insertions(+), 3 deletions(-)
> > >>
> > >> I have a bad cold and am too unfocused to trust myself poking at the code to
> > >> much right now, but adding a riscv specific elf flag printing function to lib.c
> > >> and lib.h seems a bit... ew? That's not even a generic ELF function, that's
> > >> "flags for one architecture that can't figure out what it's ABI is" elf function.
> > >
> > > heh, i almost included some arm32 flags (that i personally don't care
> > > about) just to make it look less like this is riscv-specific :-)
> > >
> > > but you're right --- they shouldn't have done it this way. funnily
> > > enough, they realized that a little later, so there's a separate
> > > attribute that does it "less badly" given the huge mess that is
> > > risc-v's "anything is possible!" ABI nightmare.
> >
> > I shouldn't rant about this but I'm sick. Pascal's apology has gone to plaid.
> >
> > Remember how I had a tinycc fork and the Windows developer Fabrice handed off
> > too was chasing my taillights until I got sick of it? Jeff apparently had a
> > similar relationship with J-core and Risc-V years ago (like, back before I met
> > him), in that he explained to them what they'd done architecturally wrong
> > multiple times until he got tired of their whack-a-mole solutions where they
> > kept adding stuff to cover every new case he'd pointed out. Meanwhile the ARM
> > guys took the superh stuff they'd licensed to make "thumb" and broke it off into
> > cortex-m which became a lot cheaper when the patents expired and they didn't
> > have to pay per-chip license fees to whichever combination of hitachi and
> > renesas that was going to anymore. (Thumb was userspace only, thumb2 you could
> > write a kernel in, and cortex-m was just thumb2 without the armv3 instructions.)
> >
> > RISC-V always struck me as one of those "infrastructure in search of a user"
> > things. Unix was a bunch of guys building a system they were actually using,
> > incorporating day to day experience as feedback to drive development decisions.
> > What I saw of RISC-V over the ~5 years I admittedly wasn't really paying
> > attention started with ivory tower academics building a system they thought
> > other people might like, and then pivoted into "attracting large venture capital
> > investments" driving their engineering decisions.
> >
> > It's entirely possible that's a biased view and I have no idea what they've done
> > recently. Maybe they got their act together and everything's great now. But I
> > just got email from a chinese developer who's confused that the "mips64"
> > toolchain on my website is "that thing SGI abandoned 20 years ago" rather than
> > Longsoon, and I thought China was the driving force behind Risc-V?
> >
> > I also don't understand how "open source development" is supposed to apply to
> > something where running a non-debug build (creating a mask with even a
> > semi-recent process) costs multiple millions of dollars in setup costs before
> > you burn your first wafer. It's nice that efabless just raised another $6
> > million to keep going but sky130 _claims_ it can do 90 nanometers if they've
> > fixed the timing problems in their openlane toolchain I was wrestling with back
> > in https://github.com/j-core/openlane-vhdl-build and meanwhile the "wow this is
> > slow" orange pi 3b I've been setting up recently is 22 nanometers (insufficient
> > L3 cache I think), yet Risc-V is _not_ going after the deeply embedded nommu
> > microcontroller market first, but instead trying to slug it out with
> > Intel/Apple/Qualcomm. Seems to me like the best case scenario would be something
> > like project Pink that produced the PowerPC in collaboration with Apple, IBM,
> > and... Motorola was it? https://en.wikipedia.org/wiki/AIM_alliance Yup,
> > Motorola. And the more likely scenario was Intel/HP partership that produced
> > https://www.wired.com/2012/02/hp-itanium/
> >
> > The full VHDL source to an actually produced 64 bit gigahertz powerpc chip is up
> > at https://github.com/OpenPOWERFoundation but nobody cares because Risc V has
> > marketing. *shrug* Ok... I'm out of the hardware business for the moment, and
> > haven't really been _properly_ in it since before the pandemic, so what do I
> > know? India was pumping tens of millions at a time into Risc-V back in 2016:
> >
> > https://www.eetimes.com/india-preps-risc-v-processors/
> >
> > Which has seen "incredible growth" to $3 million:
> >
> > https://riscv.org/blog/2023/07/the-incredible-growth-of-risc-v-in-india/
> >
> > But then shortage of money has never been their problem, since fundraising
> > always struck me as what the design was optimized for:
> >
> > https://www.datacenterdynamics.com/en/news/ai-and-risc-v-chip-company-tenstorrent-raises-100m-from-hyundai-kia-and-samsung/
> >
> > > you'll be seeing a
> > > readelf patch for that too eventually, but [right now at least] "is it
> > > using C?" and "what's the float ABI?" are fairly useful questions in
> > > their own right.
> >
> > They annotate the header with what source language it was compiled from?
>
> no, C is the risc-v "compressed" extension. (to use your thumb
> analogy, it's like neither of those: it's solely a shorter way to
> write a few of the most common instructions, not really useful on its
> own.)
>
> the E that also gets a flag will make you wince the most, though ---
> that's the "embedded" extension [for some values of "extension"] that
> loses you half your registers. (but not in the thumb way, where you
> can move between high and low; here the high registers are actually
> gone.)
>
> > > even though i don't think "which revision of the arm32 eabi is this
> > > exactly?" is useful, i think there's a reasonable argument that arm32
> > > soft-float vs hard-float is still sadly relevant in 2023 (citation
> > > needed? https://wiki.debian.org/ArmPorts), and that's in the header
> > > flags. i can send you that as a follow-up patch if you like. i just
> > > don't remember any Android app developer making that mistake before!
> > >
> > >> Tempted to glue readelf.c and file.c together into the same source file so they
> > >> can share this function that way, but lemme try to get enough soup and cold
> > >> medicine to think clearly and maybe come up with a better solution...
> > >
> > > i guess my thinking is the opposite --- the main reason i haven't sent
> > > you an nm.c yet is that it too wants the "iterate over the things in
> > > an elf file, calling this callback" stuff moved out into lib/, so i've
> > > been seeing that as inevitable but low-priority. (hence calling this
> > > function elf_print_flags() rather than print_elf_flags() --- i'm
> > > assuming there will be more elf_* functions in lib eventually.)
> >
> > Maybe in a lib/elf.c file?
>
> yeah, that was my assumption. it seems like you're moving towards just
> one .h file though? and while there are only two elf functions, a
> whole file seemed like the kind of thing that would irritate you into
> merging it into lib.c anyway :-)
>
> > A file conceptually only slightly _less_ clean than portability.c. Whoever you
> > are, the majority of the codepaths in there will NOT get tested. Gotta go out of
> > your way to see more than one or two paths through the dark woods...
> >
> > Which raises the "portability.c has a portability.h but the rest of lib/*.c
> > lives in lib/lib.h and adding elf.c to that sounds less than ideal", but lemme
> > try to revisit this tomorrow when I hope to feel less terrible.
>
> i think portability.h is legit because "it does weird shit" and may
> well need to come in a very specific point in the #include dance.
> whereas by the time you're in lib.h, everything should be fine. (and
> by the time you're in a toy, everything's included anyway, so you
> neither know nor care.)
>
> that is: "i actually think the status quo is reasonable". unless we
> ended up with _hundreds_ of functions in one particular group (which
> seems unlikely), i struggle to see much benefit from breaking lib.h
> up?
>
> > Rob