[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug gold/19140] __star_* and __stop_* symbols show up in dynamic reloca
From: |
ccoutant at gmail dot com |
Subject: |
[Bug gold/19140] __star_* and __stop_* symbols show up in dynamic relocation |
Date: |
Fri, 16 Oct 2015 21:57:32 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=19140
Cary Coutant <ccoutant at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Cary Coutant <ccoutant at gmail dot com> ---
Gold creates the __start_SECTION and __stop_SECTION symbols as section-relative
(non-absolute) symbols with default visibility. As such, they are pre-emptible,
and we will create a dynamic relocation for any reference to them. The error
message appears when trying to create a 32-bit pc-relative dynamic relocation
to a pre-emptible symbol, which may indeed overflow at runtime. The absolute
reference links cleanly, and we create a RELATIVE dynamic relocation for it.
Declaring the __start_SECTION or __stop_SECTION symbol with hidden visibility
alters this behavior, and gold will bind the pc-relative reference at link
time, and will not create a dynamic relocation for it. Likewise, linking with
-pie instead of -shared eliminates the dynamic relocations for the pc-relative
references.
Gold creates the __init_array_start symbol (and others like it) with hidden
visibility. If there is a .init_array section, the symbol is a section-relative
(non-absolute) symbol; a pc-relative reference to it does not need a dynamic
relocation, and an absolute reference generates a RELATIVE dynamic relocation.
If there is no .init_array section, gold generates an absolute symbol with
value 0; a pc-relative reference will try to generate a dynamic relocation, and
an absolute reference will bind at link time.
I believe this is all working as intended.
The Gnu linker, in my experiments:
(a) Generates the PC32 dynamic relocation with no warning.
(b) Generates __start_SECTION and __stop_SECTION symbols with local scope, so
they are not pre-emptible.
(c) Does not generate __init_array_start (et al.) in a -shared link. (They are
output as undefined symbols if referenced.)
I can see an argument for generating the __start_SECTION and __stop_SECTION
symbols with hidden visibility, but I also see value in leaving them global.
Please reopen this PR if you think we should make that change.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug gold/19140] New: __star_* and __stop_* symbols show up in dynamic relocation, rafael.espindola at gmail dot com, 2015/10/15
- [Bug gold/19140] __star_* and __stop_* symbols show up in dynamic relocation, ruiu at google dot com, 2015/10/15
- [Bug gold/19140] __star_* and __stop_* symbols show up in dynamic relocation, rafael.espindola at gmail dot com, 2015/10/16
- [Bug gold/19140] __star_* and __stop_* symbols show up in dynamic relocation,
ccoutant at gmail dot com <=
- [Bug gold/19140] __star_* and __stop_* symbols show up in dynamic relocation, ccoutant at gmail dot com, 2015/10/16
- [Bug gold/19140] __star_* and __stop_* symbols show up in dynamic relocation, ccoutant at gmail dot com, 2015/10/16
- [Bug gold/19140] __star_* and __stop_* symbols show up in dynamic relocation, rafael.espindola at gmail dot com, 2015/10/16
- [Bug gold/19140] __star_* and __stop_* symbols show up in dynamic relocation, ccoutant at gmail dot com, 2015/10/16