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

[enh]

On Wed, Feb 17, 2016 at 3: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.)

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.

 1455757325.0