https://maskray.me/blog/2022-02-06-all-about-common-symbols#no-define-common
In GNU ld, -dc only affects -r links and causes COMMON symbols to be allocated.
--no-define-common is defined to make COMMON symbols undefined for -shared.
AIUI --no-define-common is a workaround around glibc 2.1 time and not really useful.
gold confuses --define-common with -d/FORCE_COMMON_ALLOCATION and implements
--define-common with -d semantics. Its --no-define-common is incompatible with
GNU ld.
In ld.lld, b2a23cf3c0 fixed the default -r
behavior for COMMON symbols but ported the incompatible gold
--[no-]define-common. To the best of my knowledge, no project uses -dp
--[no-]define-common. So just remove these options.
-d/-dc are used by the following projects:
* grub grub-core/genmod.sh.in uses -Wl,-r,-d (https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00088.html)
* FreeBSD crunchgen uses -Wl,-dc (https://reviews.freebsd.org/D34215)
A no-op implementation works for them. Only when a program inspects relocatable
output by itself and does not recognize COMMON symbols, there may be a problem.
This is an extremely unlikely case.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D119108
to decrease sizeof(SymbolUnion) from 72 to 64 on ELF64 platforms.
Use a dummy `Undefined` to prevent null pointer dereference (though unused)
`*rel.sym` in InputSectionBase::relocateAlloc.
The relocation order may shuffle a bit, but otherwise there is no behavior
difference.
lld/ELF/OutputSections.cpp includes llvm/Config/config.h for
LLVM_ENABLE_ZLIB definition, but llvm/Config/config.h doesn't exist in
standalone build.
To fix this, this patch moves LLVM_ENABLE_ZLIB from config.h to
llvm-config.h and updates OutputSections.cpp to include llvm-config.h
instead of config.h
Reviewed By: MaskRay, mgorny
Differential Revision: https://reviews.llvm.org/D119058
SharedSymbol::SharedSymbol initializes verdefIndex and Symbol::replace
copies verdefIndex.
By move verdefIndex assignment outside of ctor, Symbol::replace can be changed
to not copy verdefIndex. This can be used to decrease work for for
ObjKind/BitcodeKind.
Currently `this->getName() == newSym.getName()`.
By keeping the old nameData/nameSize, newSym's nameData/nameSize will be
ignored. The call sites can avoid calling getName().
printTraceSymbol needs to take the symbol name since `other`'s name is empty.
* partition and isPreemptible are frequently used. Move it to the front
* move used beside isUsedInRegularObj. They are similar and accessed together in .symtab finalizing
* move auxIdx/dynsymIndex/verdefIndex to the end.
This decreases code size.
For -no-pie/-pie, when `__real_foo` is interposable in a shared object, `foo` is
exported. This rule does not match GNU ld and is unneeded because:
* the exported `foo` does not interpose `__real_foo` at run-time
* the similar `__wrap_foo` <-> `foo` relation does not have the rule
A STV_PROTECTED shared definition does not set exportDynamic of a defined
symbol. This is on the basis that a protected definition cannot be preempted so
the export is unnecessary. However, the condition is imperfect because we don't
know whether the shared object was built with a symbolic option. Since dropping
the condition simplifies code and matches GNU ld, let's do it.
There's a couple of motivations here:
* LLD 12 (which I was originally testing with) was adding an undefined
symbol to the symbol table if you attempted to wrap an unreferenced
lazy symbol, which would later break `--no-allow-shlib-undefined`. LLD
on main actually produces a weak undefined symbol, so this doesn't
break anyway, but it's cleaner to not have the weak undefined symbol
as well. The new behavior also matches bfd and gold.
* PROVIDE in a linker script referencing a wrapped symbol would think
that an otherwise-unreferenced lazy symbol which was wrapped was
actually referenced, and therefore proceed with the definition, which
goes against expectations. The new behavior also matches bfd and gold.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D118756
-fprofile-use=/-fprofile-sample-use= compiles may produce REL-format
.rel.llvm.call-graph-profile even if the prevailing format is RELA on AArch64.
Add R_AARCH64_NONE to getImplicitAddend to fix this linker error:
```
ld.lld: error: internal linker error: cannot read addend for relocation R_AARCH64_NONE
PLEASE submit a bug report to https://crbug.com and run tools/clang/scripts/process_crashreports.py (only works inside Google) which will upload a report and include the crash backtrace.
```
This diff adds support for ADRP+ADD optimization for AArch64 described in
d2ca58c54b
i.e. under appropriate constraints
ADRP x0, symbol
ADD x0, x0, :lo12: symbol
can be turned into
NOP
ADR x0, symbol
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D117614
See the updated insert-before.test for the effects: many synthetic
sections are SHF_ALLOC|SHF_WRITE. If they are discarded, we don't want
to propagate their flags to subsequent output section descriptions.
`getFirstInputSection(sec) == nullptr` can technically be merged into
`isDiscardable` but I'd like to postpone that as not sharing code may give more
refactoring opportunity.
Depends on D118529.
Reviewed By: peter.smith, bluca
Differential Revision: https://reviews.llvm.org/D118530
adjustSectionsBeforeSorting updates some output section attributes
(alignment/flags) and removes discardable empty sections. When it is called,
INSERT commands have not been processed. Therefore the flags propagation rule
may not affect output sections defined in an INSERT command properly.
Fix this by moving processInsertCommands before adjustSectionsBeforeSorting.
adjustSectionsBeforeSorting is somewhat misnamed. The order between it and
sortInputSections does not matter. With the pass shuffle, the name of
adjustSectionsBeforeSorting becomes wrong. Therefore rename it. The new
name is not set into stone. The function mixes several tasks and the
code may be refactored in a way that we may give them more meaningful
names.
With this patch, I think the behavior of attribute propagation becomes more
reasonable. In particular, in the absence of non-INSERT SECTIONS,
inserting a section after a SHF_ALLOC one will give us a SHF_ALLOC section,
not a non-SHF_ALLOC one (see linkerscript/insert-after.test).
Reviewed By: peter.smith, bluca
Differential Revision: https://reviews.llvm.org/D118529
The deduplication requires a DenseMap of the same size of the local part of
.strtab . I optimized it in e205445434 but it is
still quite slow.
For Release build of clang, deduplication makes .strtab 1.1% smaller and makes the link 3% slower.
For chrome, deduplication makes .strtab 0.1% smaller and makes the link 6% slower.
I suggest that we only perform the optimization with -O2 (default is -O1).
Not deduplicating local symbol names will simplify parallel symbol table write.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D118577
Replace `f<ELFT>(x)` with `InvokeELFT(f, x)`.
The size reduction comes from turning `link` from 4 specializations into 1.
My x86-64 lld executable is 26KiB smaller.
Reviewed By: ikudrin
Differential Revision: https://reviews.llvm.org/D118551
Previously an InputSectionBase is dead (`partition==0`) by default.
SyntheticSection calls markLive and BssSection overrides that with markDead.
It is more natural to make InputSectionBase live by default and let
--gc-sections mark InputSectionBase dead.
When linking a Release build of clang:
* --no-gc-sections:, the removed `inputSections` loop decreases markLive time from 4ms to 1ms.
* --gc-sections: the extra `inputSections` loop increases markLive time from 0.181296s to 0.188526s.
This is as of we lose the removing one `inputSections` loop optimization (4374824ccf).
I believe the loss can be mitigated if we refactor markLive.
Fangrui Song