10601 2009-09-03 21:05:00 +0000 user-space deref/registers in loc2c 2011-07-20 21:19:29 +0000 1 1 1 Unclassified systemtap runtime unspecified All All RESOLVED FIXED P2 normal --- 10289 10318 10762 10907 1 fche fche jistone mjw 38060 fche 2009-09-03 21:05:08 +0000 For secure/robust memory and register access for user-space $target expressions, the translator must parametrize loc2c to emit different calls for user-space probes than for kernel-space ones. This is partly so that user-space $pointers can't poke at kernel memories, and vice versa. Related, the user-space register/memory access logic must become aware of 32-bit vs. 64-bit user-space processes on a 64-bit host. For registers, this appears to require use of the proper utrace regset machinery instead of poking at pt_regs. 38061 jistone 2009-09-03 21:11:05 +0000 Likewise, @cast will need to learn whether its type should be treated as a user or kernel. This can't come from probe context, since @cast can appear in any probe or function. 38073 mjw 2009-09-04 07:05:24 +0000 This is the root cause of bug #10318 "Bad address reading arg from mark probe" which also contains some discussions about the implementation of this in loc2c. The register mapping disparity also seems to be the root cause of some of the exelib.exp mark.tcl tests failing (currently disabled) on 32-on-64 bit systems, bug #10289 "stap probes user space markers don't work with 32-on-64 executables". On i386 some sdt_misc.exp sdt_types tests are failing, which most likely can also be attributed to the register fetch mismatch in user space. It might be good to make comment #1 into its own bug. 40462 fche 2009-12-21 19:21:56 +0000 The basic function for loc2c purposes ($-variables) is done for i386 and x86-64. Further work needed: interfacing unwinding logic, porting to other architectures, and working on the tapset/**/register* widgets to interface to the same. 49945 mjw 2011-07-20 21:19:29 +0000 *** Bug 10318 has been marked as a duplicate of this bug. ***