Description of problem: In MIB template with breakpoint on the B slot ia64 generates SIGILL. In other cases it generates normal SIGTRAP. Version-Release number of selected component (if applicable): kernel-2.6.18-194.el5.ia64 How reproducible: Always. Steps to Reproduce: 0: 10 00 00 00 01 00 [MIB] nop.m 0x0 6: 00 00 00 02 00 80 nop.i 0x0 c: 99 99 01 00 break.b 0xccccc = http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/ia64-sigill.c?cvsroot=systemtap Actual results: SIGILL si_code==ILL_ILLOPC si_imm==0 si_segvflags==0 si_isr==0 Expected results: SIGTRAP Additional info: GDB already expects SIGILL, just it has some bugs in that logic. infrun.c: /* Note that breakpoint insns may cause SIGTRAP or SIGILL or SIGEMT, depending on the operating system version. */ I have not checked all the other template and breakpoint possibilities really generate SIGTRAP.
Reproducible on the latest build: kernel-2.6.18-207.el5.ia64 hp-rx2660-01.rhts.eng.bos.redhat.com
This is just an issue with the ia64 hardware and/or trap handler. It probably doesn't have anything to do with the mechanics of ptrace or utrace. It needs an ia64 expert more than ptrace experts. As I read the kernel source, that si_code,si_imm combination comes either via ia64_illegal_op_fault or via ia64_bad_break with break_num=0. I don't know enough about ia64 details to understand what situations lead to either of these paths or which of the two we could be seeing.
Reproducible exactly the same on: kernel-2.6.9-89.EL.ia64 ia64-4as-8-m1.ss.eng.bos.redhat.com OK, going to workaround it in GDB as a hardware bug, thanks.
This is a documented IA64 behavior as described by Tristan Gingold: http://sourceware.org/ml/gdb-patches/2010-07/msg00277.html