do you want a patch with the arm32 flags too?
On Mon, Oct 30, 2023 at 4:58 PM enh <e...@google.com> wrote: > > On Mon, Oct 30, 2023 at 4:36 PM Rob Landley <r...@landley.net> wrote: > > > > On 10/30/23 17:47, enh wrote: > > > On Mon, Oct 30, 2023 at 3:29 PM Rob Landley <r...@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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
