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
