This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/10318] Bad address reading arg from mark probe

------- Additional Comments From mjw at redhat dot com  2009-06-26 18:14 -------
Created an attachment (id=4023)
 --> (
parameterize loc2c with a callback to emit what now are deref and store_deref
macro uses

We discussed this a bit on irc (transcribed in this comment - mostly roland

The attached patch by roland is a sketch for the start of the first bit:
parameterize loc2c with a callback to emit what now are deref and store_deref
macro uses. You could also nix the used_deref tracking in loc2c and just make
stap's emit_deref callback set its tracking flag. Notice how in the patch
emit_deref has the "size" value at translation time (expr[i].number is the
size, where expr[i] is the DW_OP_deref or whatnot that we are translating), so
the callback can get an int rather than just a string of the size number as we
emit now. The point being that the new callbacks should take that int, rather
than it being hidden as a literal string of C or whatnot. deref/store_deref are
the easy ones. For proper interface in loc2c, it should have a callback to
emit.  But in fact, the stap callback will just differ in the name of the macro
it emits for kernel vs user. Next, parameterize where it emits fetch_register
and store_register macros so it uses a callback to emit, that takes the
register number as an int arg to the callback. Hopefully this patch illustrated
how to tease apart the loc2c impl macros like push() where you need to split up
what was a simple push("x = fetch_register (%d)", blah); line to have a
callback in the middle.

After the parameterization, deref et al are simple: just want a different
runtime macro that does checking like vanilla get_user()/put_user() macros do.
For fetch/store_register what you want at runtime is calls to user_regset
functions, which take byte offset and length for regset layout. What you have
at translation time is a DWARF register number, so ideally you want to
translate that to to a regset+offset at translation time and emit code that
calls the runtime for user_regset fetches from an emitted literal-number
offset. libebl has the the DWARF reg # -> regset layout mapping, but it is not
exported prettily now. It is a fixed ABI, so for now probably easiest to put
some hard-coded tables in stap for some arch's (later elfutils will make this
translation easy for stap, for now the backends/*_corenote.c files have the
tables you could translate to hard-code something). The user case callback for
emit-register would map reg# to regset+offset, then emit a
"fetch_from_regset(regset, offset)" runtime call or suchlike.


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]