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

Khem Raj raj.khem at gmail.com
Mon Oct 12 16:32:04 UTC 2015


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>:
>>
>>>
>>> On Oct 8, 2015, at 9:07 AM, Jens Rehsack <rehsack at gmail.com> wrote:
>>>
>>>
>>>> Am 08.10.2015 um 16:46 schrieb Khem Raj <raj.khem at gmail.com>:
>>>>
>>>>
>>>>> On Oct 8, 2015, at 7:33 AM, Jens Rehsack <rehsack at gmail.com> wrote:
>>>>>
>>>>>
>>>>> [Icedtee Ticket #2153] -- see http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2153
>>>>>
>>>>> This patch prevents gcc generate code on ARM5e accessing 64 bit values, because gcc doesn't ensure they're 64 bit aligned.
>>>>> Accessing a 64 bit value from a 32 bit alignment causes segmentation faults.
>>>>>
>>>>> Patch is taken from https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/gcc/0001-ARMv5-disable-LDRD-STRD.patch
>>>>
>>>> Can you try using -mfix-cortex-m3-ldrd, does that help ?
>>>
>>> Well, I have a marvel-kirkwood - I'll give it a shot but don't know whether it works at all.
>>>
>>>> The patch is a workaround to gcc, as it seems real problem is in defining instruction constraints
>>>> please open a gcc bug for this.
>>>
>>> Dunno whether I want to have all that stress. When neither ARCH linux guys did that nor Icedtea
>>> maintainers, how could I succeed there?
>>>
>>> Best I can do is (if -mfix-cortex-m3-ldrd doesn't help), keep it private. When -mfix-cortex-m3-ldrd
>>> helps, is adding it to ./meta/conf/machine/include/tune-arm926ejs.inc a sane approach?
>>
>> This might be OK. Although I would like to see it fixed in right way in gcc, we don’t want to carry patches
>> that are not accepted upstream. We already have 60 odd patches and we should reduce them if possible.
>
> I tried the approach applying -mfix-cortex-m3-ldrd to TUNE_CCARGS for armv5+dsp - and it generates
> ldrd instructions anyway. Accepted upstream or not, I have no time to get the right upstream fix.
>
> So I keep it private.
>
> 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 ?

> Want to have a patch for that or shall I keep it private, too?
>
> Cheers
> --
> Jens Rehsack - rehsack at gmail.com
>



More information about the Openembedded-core mailing list