[OE-core] [PATCH 2/2] gcc: Avoid non-aligned access for ARM5e

Jens Rehsack rehsack at gmail.com
Tue Oct 13 20:52:44 UTC 2015


> Am 13.10.2015 um 18:49 schrieb Khem Raj <raj.khem at gmail.com>:
> 
>> 
>> On Oct 13, 2015, at 4:45 AM, Otavio Salvador <otavio.salvador at ossystems.com.br> wrote:
>> 
>> Hello Jens and Khem,
>> 
>> On Mon, Oct 12, 2015 at 2:54 PM, Jens Rehsack <rehsack at gmail.com> wrote:
>>>> Am 12.10.2015 um 18:32 schrieb Khem Raj <raj.khem at gmail.com>:
>>>> On Mon, Oct 12, 2015 at 9:01 AM, Jens Rehsack <rehsack at gmail.com> wrote:
>>>>>> Am 08.10.2015 um 18:40 schrieb Khem Raj <raj.khem at gmail.com>:
>>>>> [...]
>>>>> During hacking on the fix in meta/conf/machine/ I recognized that the expected thump suffix in meta/conf/machine/include/tune-arm926ejs.inc
>>>>> isn't there and modified the line as
>>>>> 
>>>>> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
>>>>> index 335e4e0..a310c9d 100644
>>>>> --- a/meta/conf/machine/include/tune-arm926ejs.inc
>>>>> +++ b/meta/conf/machine/include/tune-arm926ejs.inc
>>>>> @@ -8,4 +8,4 @@ TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", " -mtune=arm9
>>>>> AVAILTUNES += "arm926ejs"
>>>>> ARMPKGARCH_tune-arm926ejs = "arm926ejs"
>>>>> TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
>>>>> -PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} arm926ejste"
>>>>> +PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} arm926ejste arm926ejse"
>>>>> 
>>>> 
>>>> this is ok ?
>>> 
>>> From
>>> 
>>> TUNE_FEATURES="${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
>>> 
>>> is ok probably the wrong question ;)
>>> 
>>> Setting DEFAULTTUNE to arm926ejs results in expanding PACKAGE_ARCH from TUNE_PKGARCH which is combined via
>>> "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}" in
>>> meta/conf/machine/include/arm/arch-arm.inc:12
>>> 
>>> Since ARMPKGSFX_THUMB is set to "t" (or "t2" on ARMv6+) only when thumb code should be generated and
>>> ARMPKGSFX_DSP is set to "e" when DSP is featured, both have to be recognized.
>>> 
>>> The entire construct doesn't feel "ok'ish" - but it works and is more or less reliable ...
>> 
>> I understand Khem is excitant to include more non-upstreamed patches
>> into GCC but I would prefer to have it included and Java working fine
>> than a local patch applied forever. :-(
> 
> All I am asking is to open a bug with gcc. So to get some opinion on impact of patch, workaround of this nature can
> be degarading code generation, we do not have any report on that. So that my concern was

I will check how difficult it is and report if it's a low hangin' fruit ;)

Cheers
-- 
Jens Rehsack - rehsack at gmail.com




More information about the Openembedded-core mailing list