[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug gold/23411] Different behavior when linking common symbol staticall
From: |
zenith432 at users dot sourceforge.net |
Subject: |
[Bug gold/23411] Different behavior when linking common symbol statically or to shared object |
Date: |
Tue, 17 Jul 2018 08:53:02 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=23411
zenith432 at users dot sourceforge.net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zenith432 at users dot
sourceforge
| |.net
--- Comment #10 from zenith432 at users dot sourceforge.net ---
(In reply to Alexander Monakov from comment #9)
> The ELF specification does not allow this...
Where do you read that it's disallowed? Leaving something unspecified is not
the same as disallowing it.
(In reply to Cary Coutant from comment #8)
> ... If the linker decides, based on the archive index, to include
> an IR file, it asks the plugin to provide the symbols for the
> "closer look", but the API doesn't provide a way for the linker to
> then say, "never mind, I don't need that object after all," in the case
> where the only symbol of interest happens to be a common.
gold already demonstrates how to do this...
Pluginobj::get_symbol_resolution_info
> if (static_cast<size_t>(nsyms) > this->symbols_.size())
> {
> // We never decided to include this object. We mark all symbols as
> // preempted.
> gold_assert(this->symbols_.size() == 0);
> for (int i = 0; i < nsyms; i++)
> syms[i].resolution = LDPR_PREEMPTED_REG;
> return version > 2 ? LDPS_NO_SYMS : LDPS_OK;
> }
It's a bug in ld.bfd that it ends up setting multiple prevailing defs in this
scenario. The plugin api prohibits(*) setting multiple prevailing defs, and
it's not necessary to do so in order to have lto1 purge unwanted symbol defs.
(*) https://gcc.gnu.org/wiki/whopr/driver, rules for the "All Symbols Read"
event.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object, (continued)
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object, ccoutant at gmail dot com, 2018/07/13
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object, hjl.tools at gmail dot com, 2018/07/13
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object, zenith432 at users dot sourceforge.net, 2018/07/14
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object, ccoutant at gmail dot com, 2018/07/14
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object, zenith432 at users dot sourceforge.net, 2018/07/14
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object, zenith432 at users dot sourceforge.net, 2018/07/14
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object, amonakov at gmail dot com, 2018/07/16
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object, ccoutant at gmail dot com, 2018/07/16
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object, amonakov at gmail dot com, 2018/07/17
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object,
zenith432 at users dot sourceforge.net <=
- [Bug gold/23411] Different behavior when linking common symbol statically or to shared object, zenith432 at users dot sourceforge.net, 2018/07/17