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.
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.
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.
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.
*** Bug 10318 has been marked as a duplicate of this bug. ***