[llvm-bugs] [Bug 31762] New: 3.9.1's lld and powerpc64 for -pie use: can't create dynamic relocation R_PPC64_REL24 against readonly segment

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=31762

            Bug ID: 31762
           Summary: 3.9.1's lld and powerpc64 for -pie use: can't create
                    dynamic relocation R_PPC64_REL24 against readonly
                    segment
           Product: lld
           Version: unspecified
          Hardware: Macintosh
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: markmi at dsl-only.net
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Using the simple example:

# more main.c                                                                  
                                                                               
                                        static volatile char big_area[67001] =
"This is a test";

int main ()
{
    big_area[67000] = '9';
}

(big_area is not important to seeing the problem.)

I get (the -fPIE is not required for the behavior):

# clang -fuse-ld=lld -Wl,-t -pie -fPIE main.c
/usr/lib/Scrt1.o
/usr/lib/crti.o
/usr/lib/crtbeginS.o
/tmp/main-c6f752.o
/usr/lib/libgcc_s.so
/lib/libc.so.7
/usr/lib/libgcc_s.so
/usr/lib/crtendS.o
/usr/lib/crtn.o
can't create dynamic relocation R_PPC64_REL24 against readonly segment
can't create dynamic relocation R_PPC64_REL24 against readonly segment
can't create dynamic relocation R_PPC64_REL24 against readonly segment
can't create dynamic relocation R_PPC64_REL24 against readonly segment
can't create dynamic relocation R_PPC64_REL24 against readonly segment
can't create dynamic relocation R_PPC64_REL24 against readonly segment
clang: error: linker command failed with exit code 1 (use -v to see invocation)

(This is difficult to study because it does not leave even a
partial a.out and it does not report the specifics of what
segment, what symbol, the file containing the R_PPC64_REL24
in the message or other such details.)

Even an empty C source produces that, but also including the
expected:

undefined symbol: main in /usr/lib/Scrt1.o

It appears that the R_PPC64_REL24's are some subset of. . .

/usr/lib/Scrt1.o :

00000000000000cc R_PPC64_REL24     atexit
00000000000000d8 R_PPC64_REL24     _init_tls
00000000000000f8 R_PPC64_REL24     atexit
00000000000001b4 R_PPC64_REL24     _init
0000000000000240 R_PPC64_REL24     main
0000000000000248 R_PPC64_REL24     exit
00000000000002fc R_PPC64_REL24     _fini

(That would be 6 by ignoring main, matching
the message count.)

/usr/lib/crtbeginS.o :

0000000000000040 R_PPC64_REL24     __cxa_finalize
0000000000000000 R_PPC64_REL24     .opd
0000000000000000 R_PPC64_REL24     .opd+0x0000000000000018

/usr/lib/crtendS.o :

0000000000000000 R_PPC64_REL24     .opd

main.o , if I have it produced, does not have R_PPC64_REL24
in it.

Use of the devel/powerpc64-binutils port programs does
not have this problem based on the same /usr/lib/*crt*
files indicated above (just using -B on the command
line to redirect clang's binutils use).

(On a native powerpc64 host devel/binutils programs are
appropriate and work as well.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170126/c3a32c14/attachment-0001.html>