strange SIGILL (under Xen)

[Greg Troxel <gdt%lexort.com@localhost>]

I have had a xen system for a long time, with two physical computers,
both old (2007, 2010 vintage).  I have root on ufs, data on zfs, let the
domUs nfs-mount the data, and I use ccache (also really on zfs via nfs).
I mostly build packages for 9/10 i386/amd64.   I generally did not have
problems other than speed.

I recently updated the hardware to an i7-12700, which is 12th gen,
2022ish.  I had to disable CET to get xen to boot.  With that, the
system appears to work almost entirely well.

The exception is that package builds in a domU and in the dom0 are
failing, with configure tests about object suffix failing.  If I set
IGNORE_CCACHE, they are ok -- normally PKGSRC_COMPILER includes ccache.

I uninstalled ccache and all was ok, but no cacching.

I rebuilt and installed ccache and the problem returned.

I then created ~/bin/ccache with cc a link to /usr/pkg/bin/ccache.

Running (someplace else):

  PATH=~/bin/ccache:$PATH ktrace -i cc -c morse.c

shows just the exec of "cc" which is ccache, and the problem seems to be
after reading the input.  Just after a read call with data recognizable
as the C source, I see:

  6722   6722 cc       RET   read 9511/0x2527
  6722   6722 cc       CALL  read(4,0x738d0d4cc527,1)
  6722   6722 cc       GIO   fd 4 read 0 bytes
       ""
  6722   6722 cc       RET   read 0
  6722   6722 cc       CALL  close(4)
  6722   6722 cc       RET   close 0
  6722   6722 cc       PSIG  SIGILL SIG_DFL: code=ILL_PRVOPC, addr=0x145024a5b, trap=0)
  6722   6722 cc       NAMI  "cc.core"

and ILL_PRVOPC seems to be "privileged opcode".

So far, I have found no other problems.

I wonder if ccache does something extra crazy, but that really doesn't
make sense.

I know I should rebuild ccache with debugging and see what's going on.

Any other clues/thoughts welcome.