On Mon, Oct 30, 2023 at 4:36 PM Rob Landley <[email protected]> wrote: > > On 10/30/23 17:47, enh wrote: > > On Mon, Oct 30, 2023 at 3:29 PM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
