On Wed, Feb 17, 2016 at 11: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.) > Cortex-M is ARM (Ideally it'd show up as something like "ARMv7-M", "ARMv6-M" or "ARMv8-M" to distinguish which specific version. This would probably be overly complicated for your use case - I believe these are recorded as ELF notes). > > (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.) > While '64-bit ARM' is nonsense, '32-bit AArch64' isn't (It's ILP32 - the AArch64 version of x32); so while in the common case saying "AArch64, 64-bit" would be redundant, in the uncommon case it is important. > > 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 >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
