On 20 February 2016 at 20:41, Rob Landley <[email protected]> wrote: > On Thu, Feb 18, 2016 at 8:31 PM, Owen Shepherd <[email protected]> > wrote: > > > > On Wed, Feb 17, 2016 at 11:32 PM Rob Landley <[email protected]> wrote: > >> > >> On Wed, Feb 17, 2016 at 10:22 AM, enh <[email protected]> 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.
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
