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: >> On 02/21/2016 03:39 PM, Rich Felker wrote: >> > On Sat, Feb 20, 2016 at 02:28:22PM -0600, Rob Landley wrote: >> >> On Wed, Feb 17, 2016 at 7:02 PM, enh <[email protected]> wrote: >> >>> On Wed, Feb 17, 2016 at 3:32 PM, Rob Landley <[email protected]> wrote: >> >>>> On Wed, Feb 17, 2016 at 10:22 AM, enh <[email protected]> wrote: >> >>>>> It's necessary to distinguish x86 and x86-64 to be able to recognize >> >>>>> the >> >>>>> way x32 is encoded in ELF. >> >>>> >> >>>> Hmmm. That's not fun. >> >>>> >> >>>> I note that I spent the morning teaching the code to read/display the >> >>>> dynamic linker name, so this patch won't "git am" directly. >> >>>> >> >>>> Reading the patch, we're pretending that arrch64 has nothing to do >> >>>> with arm? No mention of arm in this architecture? Ok... (I guess >> >>>> Cortex-M isn't arm either, but don't currently have an example binary >> >>>> of that to test.) >> >>> >> >>> well, you're the one who removed my original "ARM aarch64" which is >> >>> what the regular desktop file(1) says :-P >> >> >> >> But not what the linux-kernel developers ever seem to say in their >> >> patch submissions. >> > >> > Regardless of what you think about these naming choices, IMO there's >> > little value in a file(1) that does not print the names that scripts >> > using it expect to see. >> >> _What_ scripts? I don't know what would be using this. (All for >> real-world tests, but I have yet to find a build script using the file >> command. Looking at /proc, sure, but not calling file...) > > I suspect it's stuff like: case "$(file "$f")" in ... > > I'm not thinking of build scripts for packages (this would not be > remotely portable usage) but things like private admin scripts, > perhaps printer filter scripts, file preview/thumbnail generation > scripts, etc. I don't have any good examples at hand but this was the > historical justification I always saw for the rather arcane/antiquated > forms for many of the names. > >> 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. yes, their names are an awful, inconsistent historical mess, but that's how real standards tend to turn out anyway :-) 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. (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! 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". 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 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.) >> > The choice to use aarch64 instead of arm64 is >> > in some ways also a consequence of this, or rather an intentional >> > _mismatch_ with patterns that should not match. The fact that mips64 >> > and powerpc64 match mips* and powerpc* was historically very >> > problematic. >> >> grep -w? Test for 64 bit first? > > Indeed, testing for 64 first is the right approach (see musl's > configure script for an example), but the problem arises when the > existing tests were written before the 64-bit version of the platform > existed. I suspect there are lots of scripts that match arm*-*-* in > the machine tuple or arm* in `uname -m` which would have wrongly > detected "arm64" as arm. > >> Elliott was suggesting that the elf-em.h constants might be good enough, >> but that says 386 not 80386, and PPC instead of Powerpc... >> >> Seriously, standards would be nice! > > Yes, wouldn't they? :) > >> (The mime types are designed to be programattically interpreted. The >> post here about a mime type database is very interesting and I have a >> tab open. But file type output seems to be for humans...?) > > Yes, mime types are a lot more consistent but less informative than > the freeform file(1) strings. > > Rich -- 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
