Package Release Info

mold-2.34.1-bp160.1.13

Update Info: Base Release
Available in Package Hub : 16.0

platforms

AArch64
ppc64le
s390x
x86-64

subpackages

mold

Change Logs

* Fri Oct 04 2024 Martin Liška <martin.liska@hey.com>
- Update to version 2.34.1
  * [ARM32] Fixed a regression that R_ARM_TARGET1 wasn't handled as a synonym for
    R_ARM_ABS32 relocation. This issue caused some ARM32 programs to crash on
    startup if linked with mold. (186272a)
  * [RISC-V] mold now sets the STO_RISCV_VARIANT_CC dynamic tag if the ELF module
    exports a function symbol with a non-standard calling convention. (16eb513)
* Wed Sep 25 2024 Martin Liška <martin.liska@hey.com>
- Update to version 2.34.0
  * [ARM32] mold now deduplicates exception handling records in a .ARM.exidx section
    to reduce the size of the table. (742ea87)
  * [LoongArch] TLSDESC relocations are now supported. (dbaa6d7)
  * --build-id=fast is now supported for compatibility with LLVM lld. mold handles
    it as a synonym for --build-id=sha256. (afc52ee)
  * Previously, if the same symbol was provided both by a static archive and dynamic
    library, and if the symbol's visibility was hidden, mold sometimes failed to
    link it and handled the symbol as if it were undefined. Now, mold can correctly
    link such programs. (1efbe3f)
  * Under rare circumstances, mold could create corrupted binaries if they were
    linked with --retain-symbols-file. This bug has been fixed. (0ee12e4)
  * [LoongArch] R_LARCH_CALL36 relocation with a large offset is now correctly
    written. (1c32102)
  * [FreeBSD] If all thread-local variables in a program have no initial values,
    mold-produced executables could crash or misbehave on FreeBSD. This bug has been
    fixed. (f6822fb)
  * DEC Alpha support has been removed due to lack of demand. In fact, mold's Alpha
    support has never been tested for real-world programs and was likely unable to
    link them in the first place. This should not affect anyone because the last
    Alpha processor was released more than 20 years ago. (3711ddb)
* Wed Aug 07 2024 Martin Liška <martin.liska@hey.com>
- Update to version 2.33.0
  * mold gained a new linker flag --separate-debug-info to bundle debug info
    sections into a separate file instead of putting them into a main output file.
    You can optionally specify a filename in the form of
  - -separate-debug-info=<filename>. By default, a debug info file is created in
    the same directory as the main output file with the .dbg extension. mold embeds
    the debug file's filename into the main output file so that gdb can
    automatically follow the link to find debug info when debugging the main output
    file.
  * The main objective of this flag is to speed up the mold linker even more. By
    default, mold creates a separate debug file in the background after creating a
    main output file, so that you can start running the executable as soon as
    possible while mold is still working on linking its debug info sections. For
    example, linking clang with debug info normally takes ~1.70s on a Threadripper
    7980X machine, while it takes only ~0.52s with --separate-debug-info. Shaving
    off a full second in quick edit-rebuild-run cycles should improve programmers'
    productivity. If you do not want mold to work in the background, pass the
  - -no-detach option. (596ffa9)
  * mold now supports the --no-allow-shlib-undefined flag. If the option is given,
    mold checks if all undefined symbols are resolved not only for input object
    files but also for shared libraries passed to the linker. To use the feature,
    you need to pass all shared libraries, including transitively dependent ones, to
    the linker so that the linker can resolve all symbols that are available at
    runtime. (3001f02)
  * mold gained the --dynamic-list-data flag for the sake of compatibility with GNU
    ld. If the flag is given, all data symbols are exported as dynamic symbols.
    (dd8d971)
  * [x86-64] -z x86-64-v2, -z x86-64-v3, -z x86-64-v4 flags are supported. (5606087)
  * [x86-64] Recent x86-64 processors support Intel CET to protect control flow
    integrity. When the feature is enabled, the instruction that is executed
    immediately after an indirect branch must be endbr64 or a CPU fault will raise.
    In other words, it restricts the locations where the control can transfer to
    with indirect branches. Doing that makes ROP attacks harder to conduct.
  * A problem with that is the compiler needs to conservatively emit an endbr64 at
    the beginning of each global function because the compiler doesn't know whether
    or not the function's address is taken in other translation units. As a result,
    the resulting binary contains more endbr64s than necessary, weakening the
    protection.
  * mold supports the -z rewrite-endbr option to conduct a whole program analysis
    and rewrite endbr64 with nop if a function's address is not actually taken
    within the program. Previously, mold didn't take section symbols into account
    when conducting the analysis, which resulted in culling some endbr64s that must
    not be removed. Now, the bug has been fixed. We confirmed that mold can build
    itself with -z rewrite-endbr, and the resulting mold executable works fine with
    Intel CET. (ed7eec5)
  * mold now creates a .eh_frame section even if it's empty. (14a4b05)
  * [LoongArch] The following relocations are now supported: R_LARCH_TLS_LE_HI20_R,
    R_LARCH_TLS_LE_ADD_R, R_LARCH_TLS_LE_LO12_R, R_LARCH_CALL36, R_LARCH_RELAX
    (36e5b4b, 98a7cff, 2c6f379)
  * [LoongArch] Some relaxations that reduce the section size are now supported.
    (74b359f, 121f917)
  * [LoongArch] Range extension thunk support has been removed in favor of
    R_LARCH_CALL36 relocations. (47c092a)
* Thu Jun 27 2024 Martin Liška <martin.liska@hey.com>
- Update to version 2.32.1
  * Previously, shared libraries specified with --as-needed were not considered as
    "needed" if they were referenced only by weak undefined symbols. Such weak
    symbols were converted to absolute symbols at address zero at link-time.
    Although this behavior was not technically wrong, it caused a significant issue
    in a rare occasion (#1286). Now, weak undefined symbols retain --as-needed
    shared libraries. (06b5926)
  * [RISC-V] RISC-V object files contain ISA strings in the .riscv.attributes
    section. Previously, we had reported valid ISA strings containing digits as
    errors. The issue has now been resolved. (841a186)
  * [RISC-V] We no longer write dynamic relocation addends to relocated places
    because it caused static position-independent executables to crash on process
    startup in some environments. In other words, --no-apply-dynamic-relocs is
    enabled by default.
  * LTO now works on MinGW. (50bf031)
* Sun Jun 09 2024 Martin Liška <martin.liska@hey.com>
- Update to version 2.32.0
  * mold supports a feature called Identical Code Folding, or ICF. As the name
    suggests, ICF finds identical functions and merges them to reduce the size of an
    output file. This is especially effective for template-heavy C++ programs since
    templates tend to be instantiated to the same machine code for different types.
    For example, std::vector<int> is likely to be instantiated to the same code as
    std::vector<unsigned>. We've made an improvement to our ICF algorithm so that
    the --icf feature is ~50% faster than the previous version. (fa8e95a)
  * The -z rodynamic option is now supported for compatibility with LLVM lld. With
    the option, mold places the .dynamic section into a read-only segment. (9a233df)
  * Previously, mold behaved differently compared to other linkers if both -z defs
    and --undefined=ignore-in-object-files were given (#1270). Now, they override
    each other so that the mold's behavior is compatible with others. (8cd85aa)
  * Previously, --dependency-file mistakenly recorded response files as dependencies
    (#1258). This bug has been fixed. (4281f45)
  * There was a bug that mold corrupted debug info section contents when the
  - -relocatable option was given (#1265). This issue has been fixed. (08b0a16)
  * [PPC64] The R_PPC64_TPREL16_LO_DS relocation type is supported. (a8cd2e8)
  * [ARM64, PPC64, LoongArch] mold 2.31.0 or earlier may have failed with an
    assertion failure when creating a large output file (#1224). This issue has been
    resolved. (c7c8583)
* Fri May 03 2024 Martin Liška <martin.liska@hey.com>
- Update to version 2.31.0
  * mold is now up to 10% faster when linking very large, debug info-enabled
    executables such as Blender (~1.8 GiB) or Clang (~3.8 GiB), thanks to several
    improvements we've made to the string merging algorithm. (53ebcd8, d714301,
    40f6b17, c9faf3d)
  * -z start-stop-visibility=hidden is now supported so that linker-synthesized
    __start_<section-name> and __stop_<section-name> symbols can be completely
    hidden from other ELF modules. Previously, only -z
    start-stop-visibility=protected was supported. (99a5b15)
  * -Bsymbolic-non-weak and -Bsymbolic-non-weak-functions options are now supported
    for compatibility with LLVM lld. Just like lld, these options control which
    symbols are exported as dynamic symbols. -Bsymbolic-non-weak makes the linker to
    export only weak symbols, whereas -Bsymbolic-non-weak-functions makes it to
    export only weak function symbols. (7d17aa8)
  * Previously, if a linker script contains a newline character in the beginning
    four bytes of a file, it was not recognized as a linker script by mold. Now,
    mold allows newlines at the beginning of a file. (ea054cc)
  * Under rare circumstances, the INPUT linker script command may have found a
    different file than GNU ld would. Now, mold's behavior aligns with GNU ld's.
    (163975d)
  * Previously, the --repro option produced corrupted tar files. Now the bug has
    been fixed. (32c4a09)
  * mold generally guarantees that its output is reproducible, meaning that if you
    run the linker with the exact same command line options and input files, the
    output is guaranteed to be bit-for-bit identical to the previous outputs.
    However, under rare circumstances, it might produce different output due to a
    bug. It's reported that this nondeterminism caused random crashes for some
    programs (#1247). This bug has been fixed. (6463a7c)
  * mold no longer sets the address of the .text section as the entry point address
    if --entry option is not given, just like LLVM lld. (020b1a7)
  * [RISC-V] __global_pointer$ symbol is now exported from executables as required
    by the processor-specific ABI. (3df7c8e)
  * [ARM32] --long-plt option is now recognized as known option by mold. mold
    ignores the option, though, because the PLTs generated by our linker is always
    long. (d432e98)
* Sun Mar 17 2024 Martin Liška <martin.liska@hey.com>
- Update to version 2.30.0
  * We have increased the version number from 2.4.1 to 2.30.0, even though this
    release contains only minor bug fixes. This change was made to prevent GNU
    libtool from mistaking mold 2.4.1 for GNU ld 2.4.1, which led it to incorrectly
    conclude that our linker was an outdated version of the GNU linker. Bumping up
    the version number to align with GNU ld may not be the most elegant solution,
    but it is a practical approach to resolve the compatibility issue with GNU
    libtool. (c7f6a91)
  * Previously, mold may have inserted an unnecessary gap before the .bss section in
    an output file, thereby creating an extra segment for it. While not technically
    incorrect, it was certainly unnecessary. mold 2.30.0 eliminates this unnecessary
    on-disk gap for .bss. (c395da1)
  * Previously, under rare circumstances, mold might fail with the "ConcurrentMap is
    full" error message if --gdb-index was used. This bug has been resolved.
    (c60d1d0)
  * Previously, mold might generate an excessive number of "ignoring .llvm_addrsig
    section without sh_link" warnings. These warnings are now suppressed. (51f871f)
  * Sections with unknown section types are now reported as errors. (d21207c)
  * [PPC32] A crash bug related to --gc-sections has been fixed. (8eae0a3)
* Fri Mar 01 2024 Martin Liška <martin.liska@hey.com>
- Align path for document installation between openSUSE versions.
* Fri Mar 01 2024 Martin Liška <martin.liska@hey.com>
- Update to version 2.4.1
  * mold 2.4.0 or prior may promote weak dynamic symbols to strong ones under a rare
    circumstance, which caused "undefined symbol" error at runtime. The bug has been
    fixed. (50bdf39)
  * Previously, if two or more VERSION clauses in a version script match to the same
    symbol, the first one took precedence. This was incompatible with GNU ld, which
    gives the last one the highest priority, causing a Qt library link failure. This
    compatibility issue has been resolved. (e1e16bf)
  * By default, we demangle symbols in error messages so that they are easier to
    read. Previously, Rust symbols could accidentally be demangled as C++ symbols.
    Now, mold attempts to demangle symbols as Rust ones only for object files
    created by rustc. (ea9864b)
  * [RISC-V] mold now relaxes a GOT-load instruction sequence into a direct address
    materialization if the symbol address is known at link time. This relaxation
    eliminates one memory load and slightly improves the linked program's
    performance. (2ccaa81)
  * [PowerPC64 ELFv2] GCC may emit references to _savegpr0_*, _restgpr0_*,
    _savegpr1_* and _restgpr1_* symbols for the -Os command line option to optimize
    the output for code size. These symbols are not defined by any object file and
    expected to be synthesized by the linker. mold didn't use to synthesize these
    symbols, and therefore object files created with -Os sometimes failed due to
    missing symbol errors. Now, mold synthesizes these symbols. (d4ff48a)
  * [PowerPC64] R_PPC64_DTPREL16_LO_DS relocation type has now been supported.
    (6d8e6af)
  * [Illumos] On Illumos OS, absolute symbols in DSOs need to be resolved at runtime
    because the dynamic linker treats such symbols in a special manner. Previously,
    mold directly used absolute symbol addresses at link-time and did not place them
    into the dynamic symbol table. That optimization has been removed for
    compatibility with Illumos. (bed5b17, 7f8d77d)
* Thu Nov 30 2023 Martin Liška <martin.liska@hey.com>
- Update to version 2.4.0
  * mold gained the --spare-program-headers=<number> option, which adds a specified
    number of spare entries at the end of the program header. The option aims to
    make post-processing tools to add program header entries very easily. Note that
    sorting program header entries after adding new ones may be necessary to meet
    the constraints of the ELF file format. For details, see the elf(5) man page.
    (eb6c213)
  * mold's -z rewrite-endbr option rewrites superflous endbr64 instructions with nop
    as a countermeasure against control-flow highjacking attacks. Previously, this
    worked exclusively with object files compiled with -ffunction-sections,
    requiring each function to be compiled into a separate section. Starting from
    this release, -z rewrite-endbr works on object files compiled without it. In
    other words, mold is now capable of rewriting endbr64 instructions even if the
    instruction is not at the beginning of a section. (3cb8a52)
  * Previously, mold couldn't handle object files containing multiple .eh_frame
    sections. The .eh_frame is a section containing data for exception handling.
    Usually, an object file contains only one .eh_frame which describes how to
    handle exceptions for all text sections in the same file. However, on rare
    conditions, it seems ld -r creates an object file containing multiple .eh_frame
    sections. mold is now able to handle such object files. (f4c5a8a)
  * mold -run <command> is an easy way to run the given command with a virtual
    environment in which the ld command is replaced with mold. The feature is
    implemented using LD_PRELOAD to hook fork(2)-family functions. Before this
    release, some invocations of ld were not intercepted correctly because we missed
    the posix_spawnp(2) function. Now, the function is intercepted just like other
    fork(2)-family functions. (3fd1cec)
  * mold used to produce a non-working executable on a rare occasion when all
    thread-local variables lacked an initial value and the read-only data required
    alignment equal to or greater than the page size. This bug has been resolved.
    (de7d37e)
  * Previously, mold might assign a different symbol version to a symbol compared to
    GNU ld if it matches both a wildcard pattern and an exact pattern in a version
    script. Our behavior is now compatible with that of GNU ld. (0fdbace)
  * [x86-64, i686] Recent versions of LLVM emit a machine code sequence for TLSDESC
    thread-local variables that differs from GCC's, and mold previously
    mis-optimized this sequence, leading to crashes in the linked programs. In other
    words, if you are using LLVM/Clang and compile object files with
  - mtls-dialect=gnu2, mold might mis-optimize the output file. Now, the bug has
    been fixed. (000ce0e)