llvm / llvm/llvm-project

ld.lld: Remove --fortran-common

Open
#205,015 6 comments 0 reactions 0 assignees View on GitHub
lld:ELF
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.