On Sun, Feb 28, 2016 at 7:48 AM, enh <[email protected]> wrote: > On Sat, Feb 27, 2016 at 10:51 PM, Rob Landley <[email protected]> wrote: >> 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. > > and arm and aarch64? as long as the ARM and Intel names are > distinguishable, i don't care about S/390 or any of the other junk. > >> 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"? > > as far as i know, there's only one. i've never come across another, > even on Mac OS. > >>> 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 meant de facto standard. > >>> 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. > > will do.
what exact subset would you like? it's ~2MiB stripped for static and dynamic, 32 and 64, for the three families. it's ~14MiB for the same but unstripped instead. and what's the best way to deliver them? >> Rob > > > > -- > Elliott Hughes - http://who/enh - http://jessies.org/~enh/ > Android native code/tools questions? Mail me/drop by/add me as a reviewer. -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
