[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/25179] ld fails to resolve R_PPC_ADDR16_HA relocations in the .d

From: amodra at gmail dot com
Subject: [Bug ld/25179] ld fails to resolve R_PPC_ADDR16_HA relocations in the .data section
Date: Sun, 10 Nov 2019 09:00:23 +0000


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]