[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined
From: |
Maciej W. Rozycki |
Subject: |
Re: [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local |
Date: |
Fri, 20 Jan 2017 12:56:44 +0000 |
User-agent: |
Alpine 2.00 (DEB 1167 2008-08-23) |
On Thu, 19 Jan 2017, Nick Clifton wrote:
> Checking Binutils in: bfin-elf ... LD REGRESSION: PR ld/20828 dynamic symbols
> with
As noted before, `_edata' is removed with `--gc-sections' and
`--version-script' combined, where it is supposed to be exported. This is
regardless of the presence of `libpr20828.so' in the link, so it does not
seem related to PR ld/20828 (same with `bfin-uclinux', so this is a
genuine backend bug).
> Checking Binutils in: riscv32-elf ... LD REGRESSION: PR ld/20828 dynamic
> symbols with
LD segfaults with the initial `libpr20828.so' link (same with
`riscv32-linux' BTW), so this is not related to PR ld/20828.
Consequently all the subsequent dependent tests fail.
It may be something missing from the linker script used, which is
required by this port, but then LD should complain rather than crash (ISTR
`aarch64' and `arm' ports segfaulting too if `.got' and/or `.got.plt'
sections were discarded from output; this may be something worth looking
into and handling gracefully as well).
> Checking Binutils in: metag-elf ... LD REGRESSION: PR ld/20828 dynamic
> symbols with
Same as with `bfin-elf' (and likewise `metag-linux').
> Checking Binutils in: riscv64-elf ... LD REGRESSION: PR ld/20828 dynamic
> symbols with
Same as with `riscv32-elf' (and likewise `riscv64-linux').
> Checking Binutils in: x86_64-solaris2 ... LD REGRESSION: PR ld/20828 dynamic
> symbols with
There are two issues here -- one is trivial with `libpr20828.so' having
extra symbols between `_fdata' and `_edata':
Symbol table '.dynsym' contains 6 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 1 _fdata
2: 0000000000000000 0 OBJECT GLOBAL DEFAULT 1 _DYNAMIC
3: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS
_PROCEDURE_LINKAGE_TABLE_
4: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 1 _edata
5: 00000000000001b8 0 OBJECT GLOBAL DEFAULT 4 _GLOBAL_OFFSET_TABLE_
so this will be a straightforward dump pattern fix.
The other is tricky -- the sole version script used is as follows:
{ global: _edata; local: *; };
and yet LD complains:
ld: anonymous version tag cannot be combined with other version tags
(so where's the non-anonymous version tag?). I'll look into it.
> Checking Binutils in: mn10300-elf ... LD REGRESSION: PR ld/20828 dynamic
> symbols with
Same as with `bfin-elf'. I have checked `mn10300-linux' too, but all
tests fail with:
Assembler messages:
Fatal error: selected target format 'elf32-am33lin' unknown
> Checking Binutils in: score-elf ... LD REGRESSION: PR ld/20828 dynamic
> symbols with
As noted before, `_fdata' is exported with `--gc-sections' and
`--version-script' combined, where it is supposed to be removed. This
only happens in the presence of `libpr20828.so' in the link, so it may be
related to PR ld/20828. I'll have a look into it.
> Checking Binutils in: sh-elf ... LD REGRESSION: PR ld/20828 dynamic symbols
> with
Same as with `bfin-elf' (`sh-linux' is fine).
I'll see if I can figure out easily what is going on with `bfin-elf'
etc., but I am not going to dive into generic port breakage and I do
encourage port maintainers to verify their port instead.
Maciej
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, address@hidden, 2017/01/16
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/18
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/18
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, address@hidden, 2017/01/18
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/23
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/23
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/23
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/23
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/23
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/23
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/23
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/24
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/24
- [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local, cvs-commit at gcc dot gnu.org, 2017/01/24