ld.lld: Remove --fortran-common
- Dominant language
- LLVM
- Stars
- 40.5k
- Forks
- 18.7k
- PR merge metrics
- PR metrics pending
Description
Remove `--fortran-common` / `--no-fortran-common` from ld.lld (ELF), so COMMON symbols follow the same archive-member-extraction rule as ordinary definitions. To the best of my knowledge there is no public user of this feature.
CC @mandlebug, who introduced this option in [D86142](https://reviews.llvm.org/D86142) (2020) for IBM ESSL on PowerPC(?). I'd like to propose removing it, and would welcome your thoughts.
`--fortran-common` makes ld.lld replicate a legacy GNU ld rule (itself inherited from SUN's linker). From https://maskray.me/blog/2022-02-06-all-about-common-symbols :
> When a symbol is COMMON and ld sees an archive, ld checks whether the archive index provides a `STB_GLOBAL` definition of the symbol. If yes, ld extracts the archive as well. This is in contrary to the usual rule that only an undefined symbol leads to archive me
mber extraction.
This is surprising when `COMMON` and `STB_GLOBAL` definitions are mixed across archives:
> Say `b0.a` and `b1.a` are mostly identical archives, but `b0.a` objects are compiled with `-fcommon` while `b1.a` objects are compiled with `-fno-common`. If `a.o` references `b0.a`, this archive lookup behavior may cause a duplicate definition error for `ld a.o
b0.a b1.a` while `b1.a` can be shadowed by `b0.a` without the rule.
It's an awkward position-dependent behavior.
```
% ld.lld a.o b1.a b0.a && ld.lld a.o b0.a b1.a
ld.lld: warning: cannot find entry symbol _start; not setting start address
ld.lld: warning: cannot find entry symbol _start; not setting start address
% ld.lld a.o b1.a b0.a --fortran-common; ld.lld a.o b0.a b1.a --fortran-common
ld.lld: warning: cannot find entry symbol _start; not setting start address
ld.lld: error: duplicate symbol: foo
>>> defined at b.c
>>> b0.o:(foo) in archive b0.a
>>> defined at b.c
>>> b1.o:(.text+0x0) in archive b1.a
```
And it is awkward for parallel symbol resolution which I am experimenting with.
(Linker performance is critical for lld to stay competitive and not be obsoleted within a few years. Carrying a niche legacy rule that obstructs it is not a good trade....)
Contributor guide
Research direction
Start at ld.lld's ELF option handling and the --fortran-common behavior described in the issue. Remove both options so COMMON symbols use ordinary archive-member extraction, then use the command-line examples in the report to verify the position-dependent duplicate-definition behavior no longer occurs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- fortran
- Domain
- compilers, performance
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100