[OE-core] [PATCH] arch-ia32: Add x32 to MACHINEOVERRIDES

Mark Hatle mark.hatle at windriver.com
Tue Sep 11 15:53:45 UTC 2012


On 9/11/12 10:36 AM, Saul Wold wrote:
> On 09/11/2012 08:13 AM, Richard Purdie wrote:
>> On Tue, 2012-09-11 at 08:07 -0700, Saul Wold wrote:
>>> This will allow the KERNEL_FEATURES to trigger the x32 ABI via overrides
>>>
>>> Signed-off-by: Saul Wold <sgw at linux.intel.com>
>>> ---
>>>    meta/conf/machine/include/ia32/arch-ia32.inc |    1 +
>>>    1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc b/meta/conf/machine/include/ia32/arch-ia32.inc
>>> index 15f67d7..fa70e57 100644
>>> --- a/meta/conf/machine/include/ia32/arch-ia32.inc
>>> +++ b/meta/conf/machine/include/ia32/arch-ia32.inc
>>> @@ -24,6 +24,7 @@ ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "x32", "" ,d)}"
>>>    TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-mx32", "", d)}"
>>>    TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", d)}"
>>>    TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
>>> +MACHINEOVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", ":x32", "" ,d)}"
>>>
>>>    # ELF64 ABI
>>>    TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
>>
>> This is just for the kernel issue, right?
>>
>> In that case, just use ${@bb.utils.contains("TUNE_FEATURES", "mx32",
>> "xxxx", "" ,d)} in the kernel recipe code...
>>
> It's possible that there will be other recipes that need patches or
> other changes in the future, but I guess we can cross that bridge when
> we come to it.
>
> I think I will actually use the features update that Bruce just added
> from here instead.  Since multiple BSP could take advantage of x32 we
> should not have to edit each of there kernel recipes.  It should just be
> enabled based on the x32 DEFAULTTUNE.

I know there are a few other things that can (and should) change behavior based 
on the x32 flag..  but flag or override, it just changes slightly the 
implementation mechanism -- either should work as long as we consistently use it.

--Mark

> Thanks
> 	Sau!
>
>
>
>> Cheers,
>>
>> Richard
>>
>>
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>





More information about the Openembedded-core mailing list