[cfe-dev] clang-3.4 built with ud2 opcodes, and kernel trapping on ud2 during check-all

[Frank Rehwinkel]

Hi,

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?

Thanks,
-Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140127/8f8727d5/attachment.html>