Re: [PATCH v1] xen/arm: align *(.proc.info) in the linker script

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.03.2023 21:38, Julien Grall wrote:
> On 01/03/2023 17:50, Julien Grall wrote:
>> I got the answer. The problem now is gitlab only keep the artifact for 
>> the latest build and it only provide a zImage (having the ELF would be 
>> easier).
>>
>> I will try to reproduce the error on my end.
> 
> I managed to reproduce it. It looks like that after your bug patch, 
> *(.rodata.*) will not be end on a 4-byte boundary. Before your patch, 
> all the messages will be in .rodata.str. Now they are in .bug_frames.*, 
> so there some difference in .rodata.*.

Strings in .bug_frames.*? This sounds like a mistake, which - if indeed
the case - will want investigating before the conversion series is
actually considered for committing.

> That said, it is not entirely clear why we never seen the issue before 
> because my guessing there are no guarantee that .rodata.* will be 
> suitably aligned.
> 
> Anyway, here a proposal for the commit message:
> 
> "
> xen/arm: Ensure the start *(.proc.info) of is 4-byte aligned
> 
> The entries in *(.proc.info) are expected to be 4-byte aligned and the 
> compiler will access them using 4-byte load instructions. On Arm32, the 
> alignment is strictly enforced by the processor and will result to a 
> data abort if it is not correct.
> 
> However, the linker script doesn't encode this requirement. So we are at 
> the mercy of the compiler/linker to have aligned the previous sections 
> suitably.

May I suggest "aligned/padded", because it's really the tail of the
previous section which matters?

Jan

> This was spotted when trying to use the upcoming generic bug 
> infrastructure with the compiler provided by Yocto.
> 
> Link: 
> https://lore.kernel.org/xen-devel/6735859208c6dcb7320f89664ae298005f70827b.camel@xxxxxxxxx/
> "
> 
> If you are happy with the proposed commit message, then I can update it 
> while committing.
> 
> Cheers,
>