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

[Jan Beulich]

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 <jbeul...@suse.com>
---
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.)

--- 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");