$ stap -e 'probe begin{ printf("%p %d\n",-1,0) exit() }' ffffffff 4294967295 It is apparant that -1 is being pushed on the stack as a 64-bit value, and then the printf internals are pulling off only 32-bits for a pointer. Thus when it gets to the %d it is at the wrong position on the stack. The translator needs to cast the -1 down to the pointer size in the call to _stp_printf / _stp_sprintf.
Or rather, the runtime printf() should expect int64_t and narrow internally as it sees fit. After all, that's why we have "%p" there - the runtime wants to decide how big pointers are. While at it, %p should do the glibc thing and print 0xdeadbeef not just deadbeef.
Please confirm you are using an up-to-date systemtap. This sounds like an old bug.
Indeed - my CVS tree was out of date. Revision 1.4 of runtime/vsprintf.c fixed this. I'll let Frank reopen this or start a new bug if he wants to press for prepending '0x'...