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

[Rob Landley]

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?

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

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.

Rob