[qt/clang/llvm-project]: Summary of bulk changes made

Git repository change summary for qt/clang/llvm-project
Pushed by mirror-service into branch 'upstream/users/jrtc27/lld-Symbol-remove-copy-constructor'.
Changed from 0000000000000000000000000000000000000000 to 15b393ef5dc8e1d1ad844a472a8aaa65bbba891a
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit a9530be6df0743d13bab49f9eca022ee827668f5 by Jessica Clarke on 19/07/2026 at 16:16..
[NFC][test][ELF] Check DSO's ifunc2 is in .iplt in aarch64-ifunc-bti.s

This mirror's the PIE's CHECK lines, which were already stricter.
https://invent.kde.org/qt/clang/llvm-project/-/commit/a9530be6df0743d13bab49f9eca022ee827668f5

Git commit 4e1dfc1c8ecaccf0e7de350277385296a91e35b3 by Jessica Clarke on 19/07/2026 at 16:16..
[NFC][test][ELF] Improve ppc32-ifunc-nonpreemptible-(no)pic.s

Firstly, the nopic test had an unused HEX check line when it should have
been checking .got.plt, and the pic test was only checking .got2, also
ignoring .got.plt.

Secondly, the indentation for instructions was inconsistent within a
single file.

Thirdly, neither test was actually checking the code for func's IPLT
entry in .glink, only that the symbol existed as a normal function that
wasn't the same as the resolver, and the nopic test wasn't even testing
the full contents of the PLT call stub, which was inconsistent with the
pic test.

Fourthly, the pic test used the same output file for two different
links, which can be confusing when debugging.

Finally, the comment at the start of the pic test's PLT call stub had no
bearing on the immediate in use, instead being the same as the nopic's
one with the 4 subtracted from both sides (presumably trying to account
for the nopic test not having the extra .got2 entry, but neglecting the
fact that it's not using absolute addressing, and even if it were, the
addresses are entirely different).
https://invent.kde.org/qt/clang/llvm-project/-/commit/4e1dfc1c8ecaccf0e7de350277385296a91e35b3

Git commit 27e4ed3aae2865b474646cabb25aaa9902832468 by Jessica Clarke on 19/07/2026 at 16:16..
[NFC][ELF] Avoid need to copy Symbol in replaceWithDefined

Firstly, by overwriting the symbol, it will have its existing flags, so
there is no need to copy them back; all we need to do is mask out the
other bits on the existing symbol.

Secondly, copying the whole symbol just to preserve the symbol version
that gets cleared by Defined::overwrite is a waste; just copy the single
member to reinstate it.
https://invent.kde.org/qt/clang/llvm-project/-/commit/27e4ed3aae2865b474646cabb25aaa9902832468

Git commit e7115f1d1b882bfaaca9f227c3075a2e3917a4b5 by Jessica Clarke on 19/07/2026 at 16:16..
[NFC][ELF] Only create alias in handleNonPreemptibleIfunc if needed

In the no direct relocations case, the original IFUNC symbol keeps its
value, and so there's no need to create a separate alias; it's only
needed when the original symbol is being redirected to the IPLT as a
normal function symbol.

This change also shifts the isInIplt assignment to be explicit and
mirror the allocateAux/pltIdx uses, rather than relying on makeDefined
copying it, and to be clear that this is in fact deliberately and
consistently being copied like them.
https://invent.kde.org/qt/clang/llvm-project/-/commit/e7115f1d1b882bfaaca9f227c3075a2e3917a4b5

Git commit 50c55bc6e1e527833b26f19835f2f7c7ab32c332 by Jessica Clarke on 19/07/2026 at 16:16..
[NFC][ELF] Create fresh alias in handleNonPreemptibleIfunc

We don't need to copy the full symbol here, we just want an internal
alias to use for the IPLT and IGOTPLT entries and IRELATIVE relocation's
addend.
https://invent.kde.org/qt/clang/llvm-project/-/commit/50c55bc6e1e527833b26f19835f2f7c7ab32c332

Git commit 15b393ef5dc8e1d1ad844a472a8aaa65bbba891a by Jessica Clarke on 19/07/2026 at 16:16..
[NFC][ELF] Remove Symbol's unused copy constructor

Now that we are no longer copying symbols via the copy constructor we
can remove it. Given we track symbol pointers in various data structures
it can be dangerous to have multiple objects for the same symbol that
would risk being viewed inconsistently, or even moved and the original
lost, though no such cases exist upstream that I'm aware of.

Copying a symbol entirely is also a weird thing to do, and can be
inefficient, so when copies are being made it's best to be explicit
about the members to copy. This also makes it clearer to understand what
members are relevant, rather than implicitly copying all the members,
most of which aren't relevant in practice.

Whilst the copy/move constructors/assignment operators are currently
implicitly deleted due to the atomic flags member, explicitly delete
them all so they remain deleted in case that ever changes.
https://invent.kde.org/qt/clang/llvm-project/-/commit/15b393ef5dc8e1d1ad844a472a8aaa65bbba891a