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

[Jan Nieuwenhuizen]

Danny Milosavljevic writes:

>> 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)

Okay, then I guess that using -m 32 on aarch64 could make sense as a
shorthand for users.

>> 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).

OK.

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

No, mescc + mescc-tools only link statically and I don't see why that
would ever change.

> 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})

Let's do that, keep it as simple as we can and update when the need
arises.

thanks, janneke

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com