Bug 188332 - g++ 4.1.0-6 shared library build / link totally broken on s390x
g++ 4.1.0-6 shared library build / link totally broken on s390x
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
s390x Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-07 19:35 EDT by Jason Vas Dias
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-10 05:22:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jason Vas Dias 2006-04-07 19:35:48 EDT
Description of problem:

Any executable that links to a shared library, when both are produced by g++
from gcc-4.1.0-6, suffers a SIGSEGV in the global C++ initialization code on
the FC6 s390x platform - this makes building most C++ packages impossible,
eg. in the FC6 production dist-fc6-build:1 buildroot on spud.z900, in /tmp:

bash-3.1# hostname
spud.z900.redhat.com
bash-3.1# more t.cpp f.cpp
::::::::::::::
t.cpp
::::::::::::::
#include <cstdio>
#include <cstring>
#include <cctype>
#include <iostream>
int main(int argc, char **argv, char **envp){ return 0; }
::::::::::::::
f.cpp
::::::::::::::
#include <cstdio>
#include <cstring>
#include <cctype>
#include <iostream>
class f { int a; f(){ a=1; } };
bash-3.1# g++ -g -c -o t.o t.cpp
bash-3.1# g++ -g -c -o f.o f.cpp
bash-3.1# g++ -g -shared -o libf.so f.o
bash-3.1# g++ -o t t.o -L. -lf
bash-3.1# LD_LIBRARY_PATH=. ./t
Segmentation fault (core dumped)
bash-3.1# LD_LIBRARY_PATH=. gdb t core.21672
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
...

Core was generated by `./t'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /tmp/libf.so...done.
Loaded symbols for ./libf.so
Reading symbols from /usr/lib64/libstdc++.so.6...Reading symbols from
/usr/lib/debug/usr/lib64/libstdc++.so.6.0.8.debug...done.
done.
...
(gdb)#0  0x000002008000069c in ?? ()
#1  0x0000020000021980 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535)
    at
/usr/lib/gcc/s390x-redhat-linux/4.1.0/../../../../include/c++/4.1.0/iostream:76
#2  0x00000200000219c0 in global constructors keyed to f.cpp_1FD5A050_6DDE0A83
() at f.cpp:6
#3  0x0000020000021a24 in __do_global_ctors_aux () from ./libf.so
#4  0x00000200000217fc in _init () from ./libf.so
#5  0x000002000000eefc in call_init () from /lib/ld64.so.1
#6  0x000002000000f046 in _dl_init_internal () from /lib/ld64.so.1
#7  0x0000020000000c6c in _dl_start_user () from /lib/ld64.so.1
(gdb) where
(gdb) start
Breakpoint 1 at 0x8000085e: file t.cpp, line 5.
Starting program: /tmp/t

Program received signal SIGSEGV, Segmentation fault.
0x000002008000069c in ?? ()
(gdb) where
#0  0x000002008000069c in ?? ()
#1  0x0000020000021980 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535)
    at
/usr/lib/gcc/s390x-redhat-linux/4.1.0/../../../../include/c++/4.1.0/iostream:76
#2  0x00000200000219c0 in global constructors keyed to f.cpp_1FD5A050_6DDE0A83
() at f.cpp:6
#3  0x0000020000021a24 in __do_global_ctors_aux () from ./libf.so
#4  0x00000200000217fc in _init () from ./libf.so
#5  0x000002000000eefc in call_init () from /lib/ld64.so.1
#6  0x000002000000f046 in _dl_init_internal () from /lib/ld64.so.1
#7  0x0000020000000c6c in _dl_start_user () from /lib/ld64.so.1
(gdb) quit
...
bash-3.1# wc -l f.cpp
5 f.cpp

Version-Release number of selected component (if applicable):
gcc-4.1.0-6

How reproducible:
100%

Steps to Reproduce:
See above
Comment 1 Jakub Jelinek 2006-04-10 05:09:41 EDT
Speaking about totally broken is very weird, the only thing that is totally
broken is the testcase, shared libraries must be linked with -fpic or -fPIC.
When the shared library object (f.o) is compiled with -fpic or -fPIC, it works
just fine.
Nevertheless, I'll have a closer look at what exactly is going on.
Comment 2 Jakub Jelinek 2006-04-10 05:22:06 EDT
After looking closer, this is not a toolchain bug, just user error.
What happens is that in non-pic code, s390x uses 32-bit PC relative relocations
for calls and in your testcase you have _ZNSt8ios_base4InitC1Ev in executables
PLT and in libf.so's R_390_PC32DBL relocation.  But, the binary is more than
2TB far from the binary and R_390_PC32DBL is not the PLT relocation
(R_390_JMP_SLOT on s390{,x}), so the dynamic linker has to relocate it to the
slot in the binary and the relocation overflows.

Note You need to log in before you can comment on or make changes to this bug.