public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "mjw at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sources.redhat.com
Subject: [Bug translator/10318] Bad address reading arg from mark probe
Date: Fri, 26 Jun 2009 18:14:00 -0000	[thread overview]
Message-ID: <20090626181431.5369.qmail@sourceware.org> (raw)
In-Reply-To: <20090623142132.10318.mjw@redhat.com>


------- Additional Comments From mjw at redhat dot com  2009-06-26 18:14 -------
Created an attachment (id=4023)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4023&action=view)
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
talking)

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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10318

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

  parent reply	other threads:[~2009-06-26 18:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-23 14:21 [Bug translator/10318] New: " mjw at redhat dot com
2009-06-23 21:02 ` [Bug translator/10318] " mjw at redhat dot com
2009-06-24  9:07 ` mjw at redhat dot com
2009-06-24  9:43 ` mjw at redhat dot com
2009-06-24 10:01 ` mjw at redhat dot com
2009-06-24 10:54 ` roland at gnu dot org
2009-06-26 18:14 ` mjw at redhat dot com [this message]
2009-07-14  9:46 ` wenji dot huang at oracle dot com
2009-07-17 18:19 ` mjw at redhat dot com
2009-09-04  7:05 ` mjw at redhat dot com
2009-12-21 19:22 ` fche at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090626181431.5369.qmail@sourceware.org \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).