| Summary: | user-space deref/registers in loc2c | ||
|---|---|---|---|
| Product: | systemtap | Reporter: | Frank Ch. Eigler <fche> |
| Component: | runtime | Assignee: | Frank Ch. Eigler <fche> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jistone, mark |
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Project(s) to access: | ssh public key: | ||
| Bug Depends on: | |||
| Bug Blocks: | 10289, 10318, 10762, 10907 | ||
|
Description
Frank Ch. Eigler
2009-09-03 21:05:08 UTC
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. |