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 i assumed you were going for short names. (and aarch64 seems to be ARM's preferred name. it's the kernel that thinks it should be called arm64.) >> (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. i'd prefer to just use the names commonly seen in the wild. no one says "64-bit x86". >> 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). me neither, but i do think we should try to make the fields stand-alone. i don't trust myself to look at the ELF class in addition to the arch, let alone anyone else :-) >> -- 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.) no, i mean the n separate docs that the arch owners create. so aarch64 would be http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf for example. but i only have to worry about six, but it seems like you want to have all the architectures that Linux supports? but actually, the names of the constants (minus EM_ and s/_/-/) from uapi/linux/elf-em.h look fine to me. and gets us out of the business of inventing *yet another* set of names. >> 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...) i did warn you! > Rob -- 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
