[Toybox] [PATCH] Distinguish 32- and 64-bit variants in file(1) for x32.

[Owen Shepherd]

On Wed, Feb 17, 2016 at 11:32 PM Rob Landley <rob at landley.net> wrote:

> On Wed, Feb 17, 2016 at 10:22 AM, enh <enh at google.com> 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
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20160219/2114f92d/attachment-0004.htm>