Re: [bug-mes] mes target selection - currently hardcoded

[Danny Milosavljevic]

> Which reminds me: mescc currently takes a -m BITS option
> 
>   -m BITS             compile for BITS bits [32]
> 
> The idea was to mimick GCC and allow easy cross-compiling on intel
> (32->64 and 64-32).  We can keep this for intel but it probably does
> not make sense for ARM?

Technically aarch64 (ARMv8-A) includes AArch32, which is a cleaned-up
version of ARMv7-A, BUT as a mode.  That means you can't execute 32-bit
ARM code inside a 64-bit ARM process (they would call that "interworking").

If the Linux kernel is compiled for it, it does work to invoke an
ARMv7-A executable on an aarch64 machine in ARMv8-A mode.  It will
switch mode when task-switching (ARM calls it "inter-operation").
But then it can't use any ARMv8-A library in that process.

(ARMv7-A: 32 bit ARM)
(ARMv8-A: 64 bit ARM)

> I think we need a true architecture flag on mescc.  Possibly mimick
> configure and add
> 
>   --host=ARCH {armv4,x86,x86_64}
> 
> and have it default to what it got from configure.  WDYT?

Something like it, yes.

What exactly the text should be depends on the ABI we want
(if we want to support an official one).

Can it happen that a mescc-generated program dlopens a
non-mescc-generated library?

If not, who cares.

Otherwise we also have to select the exact same ABI as the
non-mescc-generated library.

The ABI specifies how the stack layout is, which registers are
allowed to be clobbered, what the alignment must be when calling
functions, where the function arguments go, how to recurse and
the resolution of symbols.

(If we don't call into other libraries but just our own we couldn't
care less about any of these things.  That would be ideal and we
would just use one of {armv4,x86,x86_64})

pgpVohYRzePlU.pgp
Description: OpenPGP digital signature