Branch: refs/heads/master
  Home:   https://github.com/tianocore/edk2
  Commit: f5d585b46b3c1912b9fadc1a541e8756e713b837
      
https://github.com/tianocore/edk2/commit/f5d585b46b3c1912b9fadc1a541e8756e713b837
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-02-02 (Sun, 02 Feb 2025)

  Changed paths:
    M BaseTools/Scripts/ClangBase.lds

  Log Message:
  -----------
  BaseTools/Scripts/ClangBase.lds: Move .entry into .text section

The GccBase.lds and ClangBase.lds ELF linker scripts have been laid out
very carefully to ensure that the memory mappings of .text and .data are
such that they can be preserved in the PE/COFF memory image. This
removes the need to update any place-relative ELF relocations when
generating the PE/COFF image, making its job much easier, and
potentially allowing it to disregard static ELF relocations altogether,
and rely solely on dynamic ELF relocations.

Adding an arbitrary .entry section before .text breaks those
assumptions, so instead of emitting it as a separate section, move its
payload to the start of .text.

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


  Commit: e5d95c786b6f25d81d754cb1d1b439a8b5c2340c
      
https://github.com/tianocore/edk2/commit/e5d95c786b6f25d81d754cb1d1b439a8b5c2340c
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-02-02 (Sun, 02 Feb 2025)

  Changed paths:
    M BaseTools/Conf/tools_def.template
    R BaseTools/Scripts/ClangBase.lds
    M BaseTools/Scripts/GccBase.lds

  Log Message:
  -----------
  BaseTools/Scripts: Merge GCC and Clang ELF linker scripts

The original reason for creating a separate version of the ELF linker
script for Clang was the difference between COMMONPAGESIZE and
MAXPAGESIZE, which can we provided on the command line to the respective
linkers (ld.bfd versus lld). That difference no longer exists, and both
use COMMONPAGE_SIZE. So there is no longer a need to maintain a fork,
which has already been going out of sync with the original for no good
reason.

So merge the two and call it GccBase.lds

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


  Commit: f2b42c83dd0086dce484eae47b87b4351426746e
      
https://github.com/tianocore/edk2/commit/f2b42c83dd0086dce484eae47b87b4351426746e
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-02-02 (Sun, 02 Feb 2025)

  Changed paths:
    M BaseTools/Scripts/GccBase.lds

  Log Message:
  -----------
  BaseTools/Scripts/GccBase.lds: Use separate R-W and RW- ELF segments

To prevent the ELF linkers from complaining about emitted ELF segments
that require both writable and executable permissions, define two
separate R-X and RW- ELF segments, and emit the output sections
explicitly into those segments as appropriate.

Note that this has no bearing on the PE image, and using a single RW-
segment would probably be fine too.

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


  Commit: 15a7d311a869737580b09a158bf86983bb766d6e
      
https://github.com/tianocore/edk2/commit/15a7d311a869737580b09a158bf86983bb766d6e
  Author: Ard Biesheuvel <a...@kernel.org>
  Date:   2025-02-02 (Sun, 02 Feb 2025)

  Changed paths:
    M BaseTools/Conf/tools_def.template

  Log Message:
  -----------
  BaseTools/tools_def: Remove no-warn-rwx-segments linker options

The linker option 'no-warn-rwx-segments' breaks both the LLVM linker and
versions of the binutils ld.bfd linker prior to 2.39.

Now that the ELF image is made up of separate R-X and RW- segments, this
warning is no longer emitted and so there is no longer a need to
suppress it either.

While at it, move GCC_DLINK_FLAGS_COMMON (which is not common but only
used by Ia32 and X64) into its only user so it can be dropped.

Signed-off-by: Ard Biesheuvel <a...@kernel.org>


Compare: https://github.com/tianocore/edk2/compare/7fd3c89ff46a...15a7d311a869

To unsubscribe from these emails, change your notification settings at 
https://github.com/tianocore/edk2/settings/notifications


_______________________________________________
edk2-commits mailing list
edk2-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-commits

Reply via email to