[PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32

Kinsey Moore kinsey.moore at oarcorp.com
Sun Nov 15 04:09:10 UTC 2020

-----Original Message-----
From: Sebastian Huber <sebastian.huber at embedded-brains.de> 
Sent: Saturday, November 14, 2020 06:24
To: Kinsey Moore <kinsey.moore at oarcorp.com>; devel at rtems.org
Subject: Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32

>On 13/11/2020 15:53, Kinsey Moore wrote:
>>>> -----Original Message-----
>>>> From: Sebastian Huber<sebastian.huber at embedded-brains.de>
>>>> Sent: Friday, November 13, 2020 04:26
>>>> To: Kinsey Moore<kinsey.moore at oarcorp.com>;devel at rtems.org
>>>> Subject: Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to 
>>>> ILP32
>>>>> On 12/11/2020 14:32, Kinsey Moore wrote:
>>>>>> The SUBALIGN(4) required on rtemsroset and rtemsrwset for ILP32 
>>>>>> builds was previously present on LP64 builds and causes no issues 
>>>>>> within RTEMS, but causes relocation/alignment issues when building libbsd.
>>>>>> This restricts those alignment changes to ILP32 builds.
>>>>> The SUBALIGN() is currently only used on aarch64 in RTEMS. Why is it necessary? The PowerPC port for example uses a single linkcmds.base for the 32-bit and 64-bit without a SUBALIGN().
>>>> The SUBALIGN was necessary because the default alignment was 8 bytes and the ILP32 code would fail during initialization while iterating over the linker sets since the upper half-word of every address was zeroed out and was being treated as another init call. Is there a preferred way to accomplish this that doesn't involve SUBALIGN?
>>> Why can't you remove all the SUBALIGN() from the linker script?
>>> For example
>>> aarch64-rtems6-ld --verbose | grep SUBALIGN
>>> has no output.
>> That output is specifically for LP64 AArch64. ILP32 linker scripts have different OUTPUT_ARCH and OUTPUT_FORMAT directives. I wasn't able to get aarch64-rtems6-ld to output an ILP32 default linker script.
>What happens if you remove all the SUBALIGN() stuff from the linker script?

The LP64 multilib variant works just fine, but the ILP32 variant crashes during init on a null pointer since the elements of the linker set are aligned on 8 byte boundaries and the iteration occurs for 4 byte pointers.


More information about the devel mailing list