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

[Rob Landley]

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.)

> (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

 1455751924.0