[PATCH] bfd/{pe, pei}-x86_64: Decrease preferred section alignment from 16 to 4

[Jan Beulich]

On 28.03.2025 10:48, LIU Hao wrote:
> 在 2025-3-28 15:36, Jan Beulich 写道:
>> On 28.03.2025 07:34, LIU Hao wrote:
>>
>> First - not (also) inlining patches makes it hard to comment.
> 
> Apologies. My email client (Thunderbird) displays attachments inline, so I don't have a habit of inlining 
> them. I will do that where it's necessary.

In certain cases I can see TB do this, yes, but in others it doesn't. In no
case have I so far seen that it displaying an attachment would also lead to
it becoming part of reply context, though. And it's primarily _that_ which
helps replying. (And maybe I'm just missing yet a few more adjustments to
my TB config.)

>> I fear you saying merely "On x86-64, sections require only 4-byte alignment.
>> For example, we compile this program with Clang for x86_64-w64-mingw32: ...
>> The alignment of `.text` is 4 when optimizing for size, and 16 when optimizing
>> for speed. The exact same behavior can be observed when compiling with MSVC, or
>> when targeting ARM64." That's an observation, yes, but there may be historical
>> reasons why default alignment was set higher. Arm64 can't realistically serve
>> as a reference. MSVC possibly can, if its behavior was consistent across many
>> versions, or if it's clear why its behavior was changed at some point. My
>> preferred reference, if any, would be MASM though. The version I have to hand
>> sets .text, .data, .rdata, and .bss to 16-byte alignment.
> 
> There's no historical reason, because nothing has changed. The very first public Microsoft compiler, for 
> Windows NT 5.2 i.e. XP 64-bit and 2003, also shows this behavior:
> 
>     ```
>     E:\lh_mouse\Desktop>cat test.c
>     int my_add(int x, int y) { return x + y; }
> 
>     E:\lh_mouse\Desktop>cl test.c /c /Os
>     Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64
>     Copyright (C) Microsoft Corporation.  All rights reserved.
> 
>     test.c
> 
>     E:\lh_mouse\Desktop>objdump -h test.obj
> 
>     test.obj:     file format pe-x86-64
> 
>     Sections:
>     Idx Name          Size      VMA               LMA               File off  Algn
>       0 .drectve      0000002f  0000000000000000  0000000000000000  0000008c  2**0
>                       CONTENTS, READONLY, DEBUGGING, EXCLUDE, NOREAD
>       1 .debug$S      00000070  0000000000000000  0000000000000000  000000bb  2**0
>                       CONTENTS, READONLY, DEBUGGING
>       2 .text         00000015  0000000000000000  0000000000000000  0000012b  2**2
>                       CONTENTS, ALLOC, LOAD, READONLY, CODE
> 
>     E:\lh_mouse\Desktop>cl test.c /c /O2
>     Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64
>     Copyright (C) Microsoft Corporation.  All rights reserved.
> 
>     test.c
> 
>     E:\lh_mouse\Desktop>objdump -h test.obj
> 
>     test.obj:     file format pe-x86-64
> 
>     Sections:
>     Idx Name          Size      VMA               LMA               File off  Algn
>       0 .drectve      0000002f  0000000000000000  0000000000000000  0000008c  2**0
>                       CONTENTS, READONLY, DEBUGGING, EXCLUDE, NOREAD
>       1 .debug$S      00000070  0000000000000000  0000000000000000  000000bb  2**0
>                       CONTENTS, READONLY, DEBUGGING
>       2 .text         00000004  0000000000000000  0000000000000000  0000012b  2**4
>                       CONTENTS, ALLOC, LOAD, READONLY, CODE
>     ```
> 
>> Best, however, would be if you were able to point to a written down statement
>> somewhere. After all there must have been a reason why this was done
>> differently from what pe-i386.c and pei-i386.c have (and maybe it was MASM's
>> behavior). In fact, if there was a change to be made here, I'd wonder why we
>> wouldn't bring x86-64 back in sync with i386. I see as much or as little
>> reason to default to 4- as to 16-byte alignment. It can, in principle, all be
>> left to the programmer. Lowering alignment now may break existing code,
>> though.
> 
> Yes MASM sets `.text` to 16-byte alignment. I don't know how to change that. Sorry.
> 
> However I would like to remind you that MSVC and Clang have integrated assemblers, therefore a) to 
> compile C code to assembly, then assemble it to object code, and b) to compile C code directly to object 
> code, might not have the same effect.

IOW you're (implicitly) suggesting we add a way for compilers to indicate to
the assembler that this is compiler-generated code, and that behavior should
be different than for hand-written assembly. There's already -f, but that
has other effects, so is very unlikely to be usable here.

>> Finally, just to double check - you did run the full testsuites, and there's
>> no fallout there at all?
> 
> I did have a look in GNU AS testsuite, and did not find any checks against alignment of outputs. In order 
> to be certain, attached are test results of current master and current mater with the proposed patch 
> applied. There's no more error.

Good. But you understand that the other binutils subdir tests also need to
pass without regressions. There definitely are tests which look for certain
section alignment. See e.g. binutils' set-section-alignment.d. (With the
defaults here that's pretty useless on x86-64 then right now; it would need
higher than 16 as command line option to actually check that the command
line option takes effect.)

Jan