On 02/27/2016 03:02 PM, enh wrote: > On Sun, Feb 21, 2016 at 8:30 PM, Rich Felker <[email protected]> wrote: >> On Sun, Feb 21, 2016 at 08:42:06PM -0600, Rob Landley wrote: >>> If the script wants to match "Intel 80386" explicitly, then do I have to >>> say that for i686? >> >> I would think it makes sense to preserve the "Intel 80386" convention >> here. There's not even a reliable way to detect that a binary is for >> "i686" anyway. > > i also think it makes sense to use the same names as the GNU file(1), > because for lack of a real standard, "what the file(1) that everybody > is is running does" is about as close as we'll get to a standard.
build/root-filesystem-powerpc/bin/toybox: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, stripped So the name there is "PowerPC or cisco 4500"? PowerPC doesn't have a vendor but cisco does? It's not even capitalized consistently. > yes, their names are an awful, inconsistent historical mess, > but that's how real standards tend to turn out anyway :-) And when Posix does that I document my deviations from the standard. :) At $DAYJOB I'm working on our clean room reimplementation of superh, which we started after Renesas abandoned the platform. I admit having that be identified as "Renesas" rankles a bit. (Especially since it was originally developed by Hitachi, and part of the reason Renesas abandoned it was some "not invented here" politics about stuff they'd inherited before the spin-off vs technology developed afterwards...) > if we think those names are too big a mess to stomach (and i can > certainly understand that POV, at least until using a cleaner set is > proven to cause trouble for actual scripts), then i think using the > constant names from the kernel's uapi/linux/elf-em.h is fine too. Newly introduced platforms tend to have EM_MANUFACTURER_ARCH and then later switch it to EM_ARCH. Here's the commit that did that for Microblaze, for example: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=69515f8b957a I was going with the arch directories because they don't change as much. I've now refined that with two additional rules: 1) If there were different 32/64 bit directories that were later merged, stick with the old names. This gives us the x86-64 and 386 you wanted, and ppc and ppc64. 2) Every numerical ID should have a unique name, which leads to some... "interesting" cases. ("thing" vs "thing-old" is easier, high 0xbeef style numbers vs the low numbers Linux accepts. But some are like tilegx and tilepro, which one is "tile"? I went with the numerically lower one for that. And sparc has three. And mips _still_ says that the 10 value isn't used, which seems to be the case, I checked a mips64 binary and it's also using 0x08...) > (they're at least fairly logical.) i am aware that they say 386 and > PPC, but if we're aiming for full compatibility with everyone else's > file(1) we don't want to go this route anyway! Is there more than one implementation here, or are we just saying "everybody else uses darwinsys.com/file"? > i don't think that any > _human_ sophisticated enough to be looking at file(1)'s output for an > ELF file is going to be confused by "386" vs "Intel 80386" or "PPC" > for "PowerPC" :-) > > on the other hand i definitely _don't_ think the world needs a _third_ > "standard". Posix doesn't standardize this! (Neither does ELF!) > i'm happy to provide a patch for either of "file(1) names" or "kernel > elf-em.h names" if we can agree on which... I actually locally fixed this up several days ago (not necessarily a final thing but the next iteration at least), I just haven't finished going through the rest of Isaac's objections yet. (I'm juggling a half-dozen things again. Trying to catch up this weekend, but today wasn't the day.) > (i can also supply hello world ELF binaries for all six architectures > Android supports, which -- even if you do set up your qemu instances > -- might still be mildly interesting because they have some slightly > different ELF notes than one sees in desktop linux ELF binaries.) That would be very helpful, thank you. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
