<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 February 2016 at 20:41, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Feb 18, 2016 at 8:31 PM, Owen Shepherd <<a href="mailto:owen.shepherd@e43.eu">owen.shepherd@e43.eu</a>> wrote:<br>
><br>
> On Wed, Feb 17, 2016 at 11:32 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br>
>><br>
>> On Wed, Feb 17, 2016 at 10:22 AM, enh <<a href="mailto:enh@google.com">enh@google.com</a>> wrote:<br>
>> > It's necessary to distinguish x86 and x86-64 to be able to recognize the<br>
>> > way x32 is encoded in ELF.<br>
>><br>
>> Hmmm. That's not fun.<br>
>><br>
>> I note that I spent the morning teaching the code to read/display the<br>
>> dynamic linker name, so this patch won't "git am" directly.<br>
>><br>
>> Reading the patch, we're pretending that arrch64 has nothing to do<br>
>> with arm? No mention of arm in this architecture? Ok... (I guess<br>
>> Cortex-M isn't arm either, but don't currently have an example binary<br>
>> of that to test.)<br>
><br>
><br>
>  Cortex-M is ARM<br>
<br>
</span>It's a nommu chip that only implements thumb instructions. It does not<br>
run conventional 32 bit (or 64 bit) arm binaries. We're talking about<br>
how ELF headers should identify the binaries they contain, and how a<br>
tool should describe what those headers say about the binary.<br></blockquote><div><br></div><div>Its ARM in an ELF sense (EM_ARM)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> (Ideally it'd show up as something like "ARMv7-M",<br>
> "ARMv6-M" or "ARMv8-M" to distinguish which specific version. This would<br>
> probably be overly complicated for your use case - I believe these are<br>
> recorded as ELF notes).<br>
<br>
</span>So you're saying arm came out with an incompatible binary format and<br>
didn't bother to identify it with a new ELF type? (armv7 will run<br>
armv3 binaries from the previous decade, i686 will run i386 binaries,<br>
but Cortex-M can't run an armv3 binary.)<br></blockquote><div> </div><div>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)</div><div><br></div><div>Additionally, an ARMv7 core won't run some ARMv3 binaries (i.e. those which were compiled for the 26-bit execution model).</div><div><br></div><div>These things get complicated and non-trivial once you have overlapping architecture supersets/subsets and do not fit into neat holes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My real limiting factor here is I don't have "hello world" binaries<br>
for each of the possible Linux ELF formats. I'd really like to add<br>
that to the test suite...<br>
<span class=""><br>
>> > (Plus it's customary to distinguish the variants,<br>
>> > so people are probably eyeballing the architecture rather than paying<br>
>> > attention to the ELF class.)<br>
>><br>
>> I moved "32-bit x86" and '64-bit x86" right next to each other. (It<br>
>> was duplicative, saying 32-bit or 64-bit and then saying x86-64 or<br>
>> aarrcchh64.)<br>
><br>
><br>
> While '64-bit ARM' is nonsense<br>
<br>
</span>The Linux guys were pretty happy to create a linux/arch/arm64<br>
directory for 64-bit arm.<br></blockquote><div><br></div><div>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.</div></div></div></div>