https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103
--- Comment #24 from Michal Meloun <m...@freebsd.org> ---
(In reply to Dimitry Andric from comment #23)
I was too brief, sorry.
'environ' symbol is exported from /lib/crt1.o with *global* binding:
# readelf -s /usr/lib/crt1.o | grep environ
46: 0000000000000008 8 OBJECT GLOBAL DEFAULT COM environ
And it's referenced (not only) from /lib/libc:
# readelf -s /lib/libc.so.7 | grep environ
3: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND environ
For final mplayer link, following command is issued:
'ld … --version-script binary.ver /usr/lib/crt1.o –lc …'
where linker script binary.ver is:
MPLAYER_1 {
# to support glibcs abhorrent backwards-compatibility hack
global: _IO_stdin_used;
local: *;
};
This script changes binding of all (but _IO_stdin_used) symbols exported by
mplayer from *global* to *local*, including ‘environ’ symbol from linked in
crt1.o. Due to this, 'environ' becomes invisible to other DSO (libc..). So
resulting binary is invalid, it cannot be run-time loaded and linker should
report this issue.
Everything above is also valid for '__progname' symbol.
Actual ld.bfd (2.30, from binutils) correctly report this problem and reject to
build invalid binary:
/usr/bin/ld: mplayer: local symbol '__progname' in /usr/lib/crt1.o is
referenced by DSO
But ld.lld(7.0.1) doesn't and silently produces invalid binary.
The lack of error report and unloadable binary is, imho, evident ld.lld bug.
I can prepare trivial testcase for this, if you want it.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
