https://sourceware.org/bugzilla/show_bug.cgi?id=33177
--- Comment #7 from Ali Bahrami <ali_swbugzilla at emvision dot com> ---
(In reply to Alan Modra from comment #6)
> I see a number of examples of dynamic symbol dumps that indicate it is
> dynamic, but not a great deal in the wording. Of .SUNW_dynsymsort it does
> say "The following symbols are always included, if present: _DYNAMIC, _end,
> _fini, _GLOBAL_OFFSET_TABLE_, _init, _PROCEDURE_LINKAGE_TABLE_, and _start."
> That could be taken to mean _G_O_T_ ought to be dynamic, but there is that
> "if present". Can I interpret that as "if present as a dynamic symbol"?
>
> You can no doubt see where I'm going with this. If nothing actually needs
> the value of _G_O_T_ in a shared library outside of that library, then why
> make it dynamic? (And if something does use the library value of _G_O_T_
> outside of a library, what is the proper value to use when multiple
> libraries are present?)
> I suppose you might use dlsym somewhere?
>
> Anyway, I suppose throwing out _G_O_T_ and others as dynamic syms no doubt
> upsets validation and testing, so it might not be worth doing.
>
> The other way to tackle this problem in gld is to implement an
> elf_add_symbol_hook for solaris to ignore _G_O_T_ and similar in shared
> libraries.
The "if present" means that those symbols are only created if
the thing they reference are present. Hence, you won't get a
_GLOBAL_OFFSET_TABLE_ symbol in an object if no GOT is
created in that object. I see code in the link-editor that
does that check. Of course, a GOT is almost always wanted
in dynamic code, so that symbol is almost always there.
Poking around, I see code in the runtime linker that
looks for that symbol, but it's bootstrap code specific
to the object itself, and not the code that does symbol
resolution between objects. I can't say definitively, but
I will guess that's why the symbol is there.
The Linker and Libraries manual calls it out explicitly as
the symbol normally used with the R_386_GOTPC relocation.
I said earlier that it was recommended for relocations that
need to access the GOT generally, but I think that was
an incorrect interpretation. And in fact on my Solaris
system, I find no relocations that do that. The following
produces no output:
% elfdump -r /usr/bin/* /lib/*.so* /lib/64/*.so* 2>&1 | grep GLOBAL
Hence, I believe we don't run into problems with objects
binding to each others GOT through this symbol, because we
don't use it in situations (relocations) where a cross object
search would be done.
As far as I know, all of this dates back to the original
code that came from Bell Labs with svr4. I do know that making
_GLOBAL_OFFSET_TABLE_ protected was done later, I think by Rod
Evans, and possibly around the time I joined Sun (late 2005).
I think it was just something he noticed while working on the
implementation for direct bindings, just a general observation
that no object should be able to bind to another object's GOT.
I'm pretty sure it wasn't done as a reaction to a bug.
If one is going to provide a symbol to be read at runtime,
then the .dynsym is the only symbol table that it could
reside in. It seems that it's "dynamic" for that reason.
Sorry I can't be more definitive about the underlying
reasons its done this way. There are layers of history I
don't fully know.
Wouldn't having gld make that symbol protected solve the
problem?
Thanks.
- Ali
--
You are receiving this mail because:
You are on the CC list for the bug.
