https://sourceware.org/bugzilla/show_bug.cgi?id=25179
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
Assignee|unassigned at sourceware dot org |amodra at gmail dot com
--- Comment #9 from Alan Modra <amodra at gmail dot com> ---
This isn't a bug, it's a feature. The linker has a choice when all the
references in an executable to a function defined in a shared library are in
read-write sections. It can create a plt call stub as is done if there is a
reference in a read-only section and define that function symbol on the plt
call stub code, or it can emit dynamic relocations. Both solutions result in a
valid executable. However, dynamic relocations have better runtime
performance: Calls to the function don't need to bounce through the plt call
stub code.
Normally the only references in read-write sections are to initialise function
pointers with an R_PPC_ADDR32 relocation. Which is probably why your ld.so
doesn't handle R_PPC_ADDR16*.
You could argue, and I'd agree, that the linker should not emit dynamic
relocations that are not supported by ld.so. It isn't a trivial task, but I'm
happy to accept patches to do that for powerpc on netbsd.
--
You are receiving this mail because:
You are on the CC list for the bug.
