Seen while running the testsuite/systemtap.base/sdt.exp: Host: Linux vm-f13-32 2.6.33.5-112.fc13.i686 #1 SMP Thu May 27 03:11:56 UTC 2010 i686 i686 i386 GNU/Linux Snapshot: version 1.2/0.147 commit release-1.2-277-gd1274b5 GCC: 4.4.4 [gcc (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2)] Distro: Fedora release 13 (Goddard) [...] Running /home/jistone/systemtap/testsuite/systemtap.base/sdt.exp ... [...] Executing on host: gcc /home/jistone/systemtap/testsuite/systemtap.base/sdt.c -g -I/home/jistone/systemtap/testsuite/../includes -Wall -Wextra -Werror -O2 -lm -o sdt.c.exe.5 (timeout = 300) /home/jistone/systemtap/testsuite/systemtap.base/sdt.c: In function ‘main’: /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:50: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:35: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:40: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:45: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:50: error: ‘asm’ operand has impossible constraints compiler exited with status 1 output is: /home/jistone/systemtap/testsuite/systemtap.base/sdt.c: In function ‘main’: /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:50: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:35: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:40: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:45: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:50: error: ‘asm’ operand has impossible constraints FAIL: compiling sdt.c additional_flags=-O2 uprobe UNTESTED: sdt additional_flags=-O2 uprobe Executing on host: gcc /home/jistone/systemtap/testsuite/systemtap.base/sdt.c -g -I/home/jistone/systemtap/testsuite/../includes -Wall -Wextra -Werror "-O3" -lm -o sdt.c.exe.6 (timeout = 300) /home/jistone/systemtap/testsuite/systemtap.base/sdt.c: In function ‘main’: /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:50: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:35: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:40: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:45: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:50: error: ‘asm’ operand has impossible constraints compiler exited with status 1 output is: /home/jistone/systemtap/testsuite/systemtap.base/sdt.c: In function ‘main’: /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:50: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:35: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:40: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:45: error: ‘asm’ operand has impossible constraints /home/jistone/systemtap/testsuite/systemtap.base/sdt.c:50: error: ‘asm’ operand has impossible constraints FAIL: compiling sdt.c additional_flags="-O3" uprobe UNTESTED: sdt additional_flags="-O3" uprobe
FWIW, I'm not seeing this on i686 rhel6 or rhel5, but on rawhide it triggers.
Actually, gazing at the assembly code generated from a less-restricted "g" constraint, the problem is not exactly the shortage of registers. The problem is that gcc -O2/-O3 was able to const-propagate/inline the STAP_PROBE* parameters as literal integer constants. The "ro" constraint doesn't let those pass. In the debuginfo-less case (STAP_SDT_V2), we could accept such literal integers (thus a weaker constraint such as "ron"), if we parsed $NNN in the translator, which we don't. In the STAP_SDT_V1 case though, any place where dwarf location expressions can extract a value would be good enough. Modern gcc can encode literals in dwarf, so "ron" or somesuch would work fine there. Older gcc would probably fail, but then again older (rhel5) gcc doesn't const-propagate this aggressively. The best option seems to: * broaden the constraint to "ron" for all platforms * teach the translator to accept "$NNN" literals in the STAP_SDT_V2 case (Note that it's not enough to go back to "g" on i686. We'd still get literals in the STAP_SDT_V2 case that the translator currently fails to parse.)
commit: 305a3c4476 Handle $N numeric literal for -DSTAP_SDT_V2 probe asm arg descriptor.