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

[enh]

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