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

[LIU Hao]

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


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


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




-- 
Best regards,
LIU Hao

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gas_master.log.gz
Type: application/gzip
Size: 1737 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20250328/61b8637e/attachment-0002.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gas_mine.log.gz
Type: application/gzip
Size: 1735 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20250328/61b8637e/attachment-0003.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/binutils/attachments/20250328/61b8637e/attachment-0001.sig>