clang-3.4 built with ud2 opcodes, and kernel trapping on ud2 during check-all


I’m trying to get the llvm-3.4 released on Jan 2, 2014 built on my x86-64 Gentoo system.

I’ve tried various combinations of cmake or gmake, gcc or clang-3.4, with and without CXXFLAGS=-std=c++98, always as Release and always with assertions enabled, but I can’t get a clang built that doesn’t have one or two dozen occurrences of the ud2 opcode in its binary. These ud2 opcodes from clang are being hit during the llvm check-all self test. The kernel log always has at least four new occurrences.

I haven’t found any references to the ud2 opcode in the cfe-dev mailing list over the last months (at least by searching through the titles) so am wondering if this is expected behaviour or perhaps my system is missing something fundamental but which neither cmake nor configure is highlighting for me.

I found the first ud2 by running gdb on a null.cpp.tmp test case that was built, and putting gdb into layout asm mode to see what instruction was triggering the trap. That’s how I learned about the ud2 opcode. Then I started dumping the assembly of the built binaries and grepping for ud2, so I can easily see how many ud2 occurrences are in the clang binary itself.

I can’t think of what I may have done to my Gentoo system to make it non-standard. It’s a pure 64-bit system so far. No support for 32-bit I think. Other than that, it’s pretty normal server except support for Xorg and development support thrown in.

Any suggestions? Just leave it and see if the traps are hit in the course of my own compiling, or dig in and figure out why my clang’s build this way?


Hi Frank,

This is normal. Clang and sanitizer testsuites include tests that
should crash in order to pass.