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

[Rob Landley]

On 02/27/2016 03:02 PM, enh wrote:
> On Sun, Feb 21, 2016 at 8:30 PM, Rich Felker <dalias at libc.org> wrote:
>> On Sun, Feb 21, 2016 at 08:42:06PM -0600, Rob Landley wrote:
>>> If the script wants to match "Intel 80386" explicitly, then do I have to
>>> say that for i686?
>>
>> I would think it makes sense to preserve the "Intel 80386" convention
>> here. There's not even a reliable way to detect that a binary is for
>> "i686" anyway.
> 
> i also think it makes sense to use the same names as the GNU file(1),
> because for lack of a real standard, "what the file(1) that everybody
> is is running does" is about as close as we'll get to a standard.

build/root-filesystem-powerpc/bin/toybox: ELF 32-bit MSB  executable,
PowerPC or cisco 4500, version 1 (SYSV), statically linked, stripped


So the name there is "PowerPC or cisco 4500"? PowerPC doesn't have a
vendor but cisco does? It's not even capitalized consistently.

> yes, their names are an awful, inconsistent historical mess,
> but that's how real standards tend to turn out anyway :-)

And when Posix does that I document my deviations from the standard. :)

At $DAYJOB I'm working on our clean room reimplementation of superh,
which we started after Renesas abandoned the platform. I admit having
that be identified as "Renesas" rankles a bit. (Especially since it was
originally developed by Hitachi, and part of the reason Renesas
abandoned it was some "not invented here" politics about stuff they'd
inherited before the spin-off vs technology developed afterwards...)

> if we think those names are too big a mess to stomach (and i can
> certainly understand that POV, at least until using a cleaner set is
> proven to cause trouble for actual scripts), then i think using the
> constant names from the kernel's uapi/linux/elf-em.h is fine too.

Newly introduced platforms tend to have EM_MANUFACTURER_ARCH and then
later switch it to EM_ARCH. Here's the commit that did that for
Microblaze, for example:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=69515f8b957a

I was going with the arch directories because they don't change as much.
I've now refined that with two additional rules:

1) If there were different 32/64 bit directories that were later merged,
stick with the old names. This gives us the x86-64 and 386 you wanted,
and ppc and ppc64.

2) Every numerical ID should have a unique name, which leads to some...
"interesting" cases. ("thing" vs "thing-old" is easier, high 0xbeef
style numbers vs the low numbers Linux accepts. But some are like tilegx
and tilepro, which one is "tile"? I went with the numerically lower one
for that. And sparc has three. And mips _still_ says that the 10 value
isn't used, which seems to be the case, I checked a mips64 binary and
it's also using 0x08...)

> (they're at least fairly logical.) i am aware that they say 386 and
> PPC, but if we're aiming for full compatibility with everyone else's
> file(1) we don't want to go this route anyway!

Is there more than one implementation here, or are we just saying
"everybody else uses darwinsys.com/file"?

> i don't think that any
> _human_ sophisticated enough to be looking at file(1)'s output for an
> ELF file is going to be confused by "386" vs "Intel 80386" or "PPC"
> for "PowerPC" :-)
> 
> on the other hand i definitely _don't_ think the world needs a _third_
> "standard".

Posix doesn't standardize this! (Neither does ELF!)

> i'm happy to provide a patch for either of "file(1) names" or "kernel
> elf-em.h names" if we can agree on which...

I actually locally fixed this up several days ago (not necessarily a
final thing but the next iteration at least), I just haven't finished
going through the rest of Isaac's objections yet.

(I'm juggling a half-dozen things again. Trying to catch up this
weekend, but today wasn't the day.)

> (i can also supply hello world ELF binaries for all six architectures
> Android supports, which -- even if you do set up your qemu instances
> -- might still be mildly interesting because they have some slightly
> different ELF notes than one sees in desktop linux ELF binaries.)

That would be very helpful, thank you.

Rob

 1456642285.0