https://sourceware.org/bugzilla/show_bug.cgi?id=32969
--- Comment #1 from Jens Remus <jremus at linux dot ibm.com> ---
The build of BCC mixes C++ modules compiled with GCC and Clang. GCC and Clang
on s390x may apparently emit COMDAT sections with C++ type information with
different section alignment:
$ cat sample.cpp
#include <typeinfo>
struct A {};
const std::type_info &q() { return typeid(A); }
$ g++ -c sample.cpp -o sample_gcc.o
$ clang++ -c sample.cpp -o sample_clang.o
$ readelf -WS sample_gcc.o sample_clang.o
Produces (reformatted and reduced):
File Name Off Size ES Flg Lk Inf Al
sample_gcc.o .rodata._ZTS1A 000080 000004 00 AG 0 0 2
sample_clang.o .rodata._ZTS1A 000058 000003 00 AG 0 0 1
In the BCC build the GNU linker erroneously relaxed the GOT access (rewrote
"lgrl rX, <sym>@GOTENT" to "larl rX, <sym>") to such type information, despite
it ending up to be on an odd address (larl only supports even addresses).
For modules that both access the symbol information and define one of the
instances (COMDAT sections) that get deduplicated, the decision is made based
on symbol information and COMDAT section information from that module (as the
relocation within that module refers to those). For the GCC compiled module
the 2-byte GCC-emitted section alignment was taken into account, so that the
linker decided to rewrite lgrl to larl. For the Clang compiled module the
1-byte Clang-emitted section alignment. During deduplication of COMDAT
sections the Clang instance remained and the GCC one got removed. This caused
the type information to end up on a 1-byte boundary.
The GNU linker needs to take the final address of a symbol into account, so
that it does not erroneously rewrite lgrl to larl for misaligned symbols.
--
You are receiving this mail because:
You are on the CC list for the bug.
