Re: [PATCH 2/6] symbols: don't over-align generated data

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.03.2025 17:07, Andrew Cooper wrote:
> On 13/03/2025 1:53 pm, Jan Beulich wrote:
>> x86 is one of the few architectures where .align has the same meaning as
>> .balign; most other architectures (Arm, PPC, and RISC-V in particular)
>> give it the same meaning as .p2align. Aligning every one of these item
>> to 256 bytes (on all 64-bit architectures except x86-64) is clearly too
>> much.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Thanks.

>> ---
>> Even uniformly aligning to 4 (x86, Arm32) or 8 bytes is too much imo,
>> when some of the items require only 1- or 2-byte alignment.
> 
> It matters about the largest item, not the smallest.

The labels we generate are all followed by uniform-granularity data.
Labels starting arrays of bytes or shorts are nevertheless 4- or 8-byte
aligned.

>> Is there a reason only x86 defines SYMBOLS_ORIGIN, to halve the address
>> table in size? (Arm32 and other possible 32-bit ports of course have no
>> need for doing so, but for 64-bit ones that can make quite a bit of a
>> difference.)
> 
> I think the likely answer is that noone really understands how the
> symbol generation works, and didn't know that setting SYMBOLS_ORIGIN
> would be relevant.

Hmm, I didn't consider this might be the reason, but you may well be right.

Jan