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

Commit Message

Jan Beulich March 13, 2025, 1:53 p.m. UTC

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 <[e-mail]>
---
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.

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.)

Comments

Andrew Cooper March 13, 2025, 4:07 p.m. UTC | #1

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 <[e-mail]>

Reviewed-by: Andrew Cooper <[e-mail]>

> ---
> 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.

>
> 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.

I had a nasty interaction with the symbol code for the IDT-gen work, and
it took a while to even get this intermediate file out.

~Andrew

Jan Beulich March 13, 2025, 4:12 p.m. UTC | #2

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 <[e-mail]>
> 
> Reviewed-by: Andrew Cooper <[e-mail]>

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

Patch

--- a/xen/tools/symbols.c
+++ b/xen/tools/symbols.c
@@ -304,10 +304,10 @@  static void write_src(void)
 	printf("#include <xen/config.h>\n");
 	printf("#if BITS_PER_LONG == 64 && !defined(SYMBOLS_ORIGIN)\n");
 	printf("#define PTR .quad\n");
-	printf("#define ALGN .align 8\n");
+	printf("#define ALGN .balign 8\n");
 	printf("#else\n");
 	printf("#define PTR .long\n");
-	printf("#define ALGN .align 4\n");
+	printf("#define ALGN .balign 4\n");
 	printf("#endif\n");
 
 	printf("\t.section .rodata, \"a\"\n");