ping?
On Tue, Dec 9, 2025 at 11:33 AM enh <[email protected]> wrote: > > On Mon, Dec 8, 2025 at 5:25 PM Rob Landley <[email protected]> wrote: > > > > On 12/5/25 13:16, enh wrote: > > > These are the arm/arm64/x86-64 ones special cased by binutils and llvm. > > > > #defining EM_ARM when it's in both elf.h and linux/elf-em.h seems like > > it should either use the header or be in portability.h? We haven't > > #defined any EM_BLAH symbols here before that, missing chunk of > > policy/design decision. Posix noped out of elf.h and LSB died. I dunno > > if this command is supposed to build on bsd or macos? (MacOS is mach-o > > but all the other bsds were elf last I checked?) > > it's actually pretty useful to have this on macOS. (less useful than > it used to be, now they're using llvm-readelf so the system readelf > handles elf as well as mach-o, but there are still things that toybox > readelf does a bit better [though i should probably put more effort > into upstreaming android-specific stuff to llvm].) > > but, yeah, moving them up into portability.h (or lib.h, where the elf > _functions_ are) makes sense. > > > The #define DO_FLAG() with the if/else stack really seems like it wants > > to be a loop over an array. Hmmm... The key and the bits are pretty much > > the same logic. Is lower case 'x' ever actually output? (We could put a > > space there and just not stick it in the key.) > > yes, it is. right now because we don't support arm64 'y' and that's > pretty common, but in general there are reserved ranges for > os-specific and processor-specific bits and (a) toybox doesn't cover > all of both of those and (b) in general it's not possible to _know_ > you have everything so it's useful to have a "oh, and there was other > stuff i didn't understand --- you might need a more specific tool [or > to teach toybox readelf a new trick]" signal. > > > Is there a big downside > > to the key having "(y) purecode" and "(l) large" in the output on > > architectures that don't support them so we're not making the help text > > conditional? > > probably that there's no reason to keep them distinct (because these > are the processor-specific flags). > > (and being conditional like this matches binutils/llvm.) > > > I can take a stab at changing that but I'm not really a heavy user of > > this command... > > > > > There's also a hexagon flag, > > > > Someday, Taylor Simpson may get the comet board emulation upstream into > > qemu so there's a proper qemu-system-hexagon that can actually boot > > kernels. At which point I'll need to start building LLVM again because > > they abandoned gcc support when it went GPLv3 and were switching to > > Open64 until I introduced them to LLVM... > > technically hexagon binaries do exist on android's vendor partition > for qcom devices so -- although i can't remember the last time i > needed to look at one -- i can add that too if you want it ... might > help someone at qcom one day :-) > > interestingly, looking at llvm it looks like hexagon's one flag isn't > labelled --- it's just ignored to surpress the 'x' in that special > case: > ``` > const EnumEntry<unsigned> ElfHexagonSectionFlags[] = { > ENUM_ENT(SHF_HEX_GPREL, "") > }; > ``` > > (dumpers that don't tell the whole truth are a pet peeve of mine. > that's one reason why toybox readelf is already a bit more literal > than others; not lying to you if there are a bunch of null entries in > your dynamic headers, say, just because some old toolchains would spam > them and someone thought it was a good idea to just pretend they > weren't there ... "double facepalm".) > > > > two xcore flags (whatever xcore is), > > > > XMOS Xcore... Wikipedia [citation needed] says Xmos is a 20 year old UK > > semiconductor company that did a "pivot to AI" earlier this year and are > > thus 100% dead (but may not know it yet). > > eh, it's hard these days to know whether it's really that or just > https://en.wikipedia.org/wiki/AI_washing because the bubble's so bad > that it's the only way to get/continue funding. (but, yeah, they may > regret that when the bubble bursts.) > > > In any case they became yet > > another undifferentiated riscv vendor in 2022. > > > > > and a > > > bunch of mips flags, but none of those seem to actually produce any > > > output, so this patch just ignores those esoterica. > > > > At one point I had stuff detecting FDPIC binaries on sh, but it was just > > "if it's sh and has this bit set", dunno what "proper" macros for it > > would be... > > for arm (and xtensa, apparently) it's the EI_OSABI field. > > for sh, yeah, it looks like it's an arch-specific bit in the e_flags > field instead. so that would go in elf_print_flags() with the existing > arch-specific stuff. as for the names of the magic numbers, the kernel > uses these: > ``` > /* ELF header e_flags defines */ > #define EF_SH_PIC 0x100 /* -fpic */ > #define EF_SH_FDPIC 0x8000 /* -mfdpic */ > ``` > > > Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
