[Bug gold/19140] __star_* and __stop_* symbols show up in dynamic relocation

[ccoutant at gmail dot com]

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.