Closed Bug 973977 Opened 10 years ago Closed 10 years ago

[ppc64] xptcall fails to build with binutils 2.24

Categories

(Core :: XPCOM, defect)

PowerPC
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: uweigand, Assigned: uweigand)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20140201104901

Steps to reproduce:

Build mozilla on a ppc64 system with binutils 2.24


Actual results:

Build fails with linker errors:

/home/uweigand/bin/ld: ../../xpcom/reflect/xptcall/src/md/unix/xptcstubs_ppc64_linux.o: In function `.nsXPTCStubBase::Stub249()':
 1:02.94 xptcstubs_ppc64_linux.cpp:(.text+0x7b4): call to `SharedStub' lacks nop, can't restore toc; recompile with -fPIC



Expected results:

Successful build.
The STUB_ENTRY macro in xpcom/reflect/xptcall/src/md/unix/xptcstubs_ppc64_linux.cpp contains the following inline assembler:

        "li     11,"#n" \n\t"                                           \
        "b      SharedStub \n"                                          \

which implements a "tail call" from the various nsXPTCStubBase::StubXXX routines to "SharedStub".  The latter is defined in xpcom/reflect/xptcall/src/md/unix/xptcstubs_asm_ppc64_linux.s as a global function symbol.

Now, the ppc64 ABI does not allow tail calls to a symbol that might reside in another module (and thus require a PLT call).  The reason for that is that PLT calls need to load the TOC pointer for the new module into r2; once the called function returns, the original value of r2 needs to be restored.  To do that, the linker replaces the instruction after the branch-and-link with a load instruction to restore r2.

If we do not actually have a call (branch-and-link) but a tail call (branch) instruction, this is impossible this control will never return to the call site.  Therefore, the current linker fails to create an executable.  Note that prior linkers did not have the check and simply generated code that would silently fail if the target symbol is in another module.

This problem used to be not an issue for Mozilla, since the SharedStub routine normally always is in the same module as the ::StubXXX routines.  However, since SharedStub is defined as a global symbol, it *could* in theory happen that a pre-existing definition of another routine called SharedStub e.g. in the main executable or in an earlier shared library could override the definition in libxul.so.

To fix this, the simplest solution seems to be to mark SharedStub as hidden symbol; this forces the linker to have the ::StubXXX routines always use the SharedStub definition in libxul.so, which is what we want anyway.  This makes the above error message go away and fixes the build failure.
Hardware: x86_64 → PowerPC
Attachment #8377670 - Flags: review?(benjamin)
Comment on attachment 8377670 [details] [diff] [review]
Mark SharedStub hidden to fix ppc64 build failure

Thanks for the patch!
Attachment #8377670 - Flags: review?(benjamin) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/10a99967ccec
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: