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.) > (Plus it's customary to distinguish the variants, > so people are probably eyeballing the architecture rather than paying > attention to the ELF class.) I moved "32-bit x86" and '64-bit x86" right next to each other. (It was duplicative, saying 32-bit or 64-bit and then saying x86-64 or aarrcchh64.) I pondered changing it to add a -64 extension for 64 bit platforms instead of saying "xx-bit", but that would give us alpha-64 and s390-64. > If we're not going to use the same strings as traditional file(1) -- which > is what I'd tried to do I can move it back to more traditional "file" output, but we're not matching exactly (missing a number of fields) and there's no spec. And that was _before_ I added dynamic linker output so you can distinguish glibc/bionic/musl/uClibc binaries... I really don't know what users expect from this. The --mime-type output seemed far more easily machine readable (which we haven't started on yet). > -- we should probably use the strings from the ELF > spec rather than the Linux kernel, Maybe it's changed since 2010, but when I was digging into this then (for hexagon), the last time the ELF spec had been updated was something like 1995, and the documents were stale snapshots hosted on a sco.com website. I believe that the Linux Foundation has since taken over the hosting, but I'm unaware of them actually acting as a standards body for this. Nor were there actually "standards" even for some old platforms like Alpha. By "standard" do you mean the values in the glibc elf.h file? (Trust glibc over the kernel? I was using the kernel to avoid coming up with my own policy decision out of the blue.) > which often deliberately goes against > the manufacturer's wishes: "arm64" versus "aarch64", for example. But that's > an issue for another day. Ah, manufacturer's naming wishes: http://www.xbitlabs.com/news/cpu/display/20040310223922.html It's a "bud" lite, clearly. (Can of worms, this command...) Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
