[Toybox] [PATCH] Distinguish 32- and 64-bit variants in file(1) for x32.
Owen Shepherd
owen.shepherd at e43.eu
Sun Feb 21 05:15:04 PST 2016
On 20 February 2016 at 20:41, Rob Landley <rob at landley.net> wrote:
> On Thu, Feb 18, 2016 at 8:31 PM, Owen Shepherd <owen.shepherd at e43.eu>
> wrote:
> >
> > 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
>
> It's a nommu chip that only implements thumb instructions. It does not
> run conventional 32 bit (or 64 bit) arm binaries. We're talking about
> how ELF headers should identify the binaries they contain, and how a
> tool should describe what those headers say about the binary.
>
Its ARM in an ELF sense (EM_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).
>
> So you're saying arm came out with an incompatible binary format and
> didn't bother to identify it with a new ELF type? (armv7 will run
> armv3 binaries from the previous decade, i686 will run i386 binaries,
> but Cortex-M can't run an armv3 binary.)
>
But "Cortex-M" (v6-M/v7-M) will run some ARMv4T binaries, and "Cortex-A"
will run most ARMv6-M or ARMv7-M binaries (those which don't use "system
mode" instructions). If you tell GCC to compile for "-march=armv7" it'll
compile for a subset of v7-M, v7-A and v7-R. (where v7-A and v7-R are
mostly identical)
Additionally, an ARMv7 core won't run some ARMv3 binaries (i.e. those which
were compiled for the 26-bit execution model).
These things get complicated and non-trivial once you have overlapping
architecture supersets/subsets and do not fit into neat holes.
My real limiting factor here is I don't have "hello world" binaries
> for each of the possible Linux ELF formats. I'd really like to add
> that to the test suite...
>
> >> > (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
>
> The Linux guys were pretty happy to create a linux/arch/arm64
> directory for 64-bit arm.
>
64-bit ARM in an ELF sense (EM_ARM, not EM_AARCH64). There is no 64-bit
execution mode for the AArch32 sub-architecture, that is, that which
implements the A32/T32 instruction sets and is implemented by ARMv7 and
earlier cores.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20160221/c73b9687/attachment-0001.htm>
More information about the Toybox
mailing list