PowerPC64 C++ exceptions with clang/llvm

Roman Divacky rdivacky at freebsd.org
Wed May 24 11:44:14 UTC 2017


Currently C++ exceptions don't work on PowerPC64 when compiled with clang. I
looked at why and discovered the following.

With the default gcc unwinder and libstdc++ this simple test program:

#include <iostream>

	int main()
	  try {
	    std::cout << "Before\n";
	    throw std::exception();
	    std::cout << "After\n";
	  } catch (...) {
	    std::cout << "Exception\n";

segfaults right after printing "Before\n". This is because the .eh_frame is corrupted and
the personality relocation is wrong:

<    1>	version				1
	cie section offset		56 0x00000038
	augmentation			zPLR
	code_alignment_factor		4
	data_alignment_factor		-8
	return_address_register		65
	eh aug data len 0xb bytes 0x94 00 00 00 01 00 01 02 ed 14 1b 
	bytes of initial instructions	3
	cie length			28
	initial instructions
	 0 DW_CFA_def_cfa r1 0

the personality relocation is "00 00 00 01 00 01 02 ed" encoded as pc relative. The program segfaults
because this address is wrong. The 33rd bit is incorrect, the real address should be "00 00 00 00 00 01 02 ed".
The same problem applies for LDSA encoding. Both personality and LDSA relocations are produced by CFI instructions
in the assembler source code.

I verified this theory by hacking the gcc unwinder and libsupc++ &= the address with 0xffffffff; and that made
the application work. (the full patch can be found at http://www.vlakno.cz/~rdivacky/ppc64.exceptions.hack.patch).

I checked why this relocation is wrong and it turns out it's our old in-tree ld that (wrongly) produces this.
Our old gcc does not use CFI to produce these and hardcodes the CIE manually and produces correct address. And for
some reason ld is fine with that.

When I compile and assemble the above source code using clang++ and only use newer ld linker from ports the resulting
binary is correct and works as expected.

So this is a bug in our in-tree ld linker. I don't know why ld has this bug but given Mark Millard's report of ld
being broken for other stuff (kernel iirc) I am not going to bother trying to fix it. I suspect it might be related
to comdats but I didn't really investigate.

I didn't try the situation with the LLVM unwinder and libcxxrt, but I hope it might be the same.

Thank you, Roman

More information about the freebsd-toolchain mailing list