public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Chuck Ebbert <76306.1226@compuserve.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Hideo Aoki <haoki@redhat.com>,
	Satoshi Oshima <soshima@redhat.com>,
	        Yumiko Sugita <yumiko.sugita.yf@hitachi.com>,
	        systemtap <systemtap@sourceware.org>
Subject: [RFC] Proposal of marker implementation
Date: Thu, 10 Aug 2006 17:45:00 -0000	[thread overview]
Message-ID: <200608101343_MC3-1-C7B1-9E82@compuserve.com> (raw)

In-Reply-To: <44D97397.2080005@hitachi.com>

On Wed, 09 Aug 2006 14:33:11 +0900, Masami Hiramatsu wrote:

> I'd like to suggest my marker idea which I spoke in OLS.
> My idea is based on the "section" of elf binary and the djprobe.
>
> Here is the concept code on i386 architecture.
> ---
> #define __MARKER_NOP(name) \
>         asm volatile ("771:\n\t" ASM_NOP6 "\n772:\n"            \
>                       ".section .markers,\"a\"\n"               \
>                       "  .align 4\n"                            \
>                       "  .long 771b\n"            /* label */   \
>                       "  .byte 772b-771b\n"       /* length */  \
>                       "  .string \"" #name "\"\n" /* name */    \
>                       ".previous\n"                             \
>                       ::: "memory")

Why do you clobber memory?

If you explicitly clobber "eax", "ecx", "edx" you can safely change your
no-op into a C function call, assuming no problems with preempt and/or
SMP synchronization.

Even if you have to use a 1-byte no-op and replace it with Int3 there
could be some advantages to your approach:
        a. No worry about caller-saved regs if the marker clobbers them.
        b. Don't need to save the replaced byte because it's always 0x90.
        c. No need to execute the replaced insn out-of-line since it's
           a no-op.
        d. Solves the problem of "first instruction in a function is
           part of a loop."

-- 
Chuck

             reply	other threads:[~2006-08-10 17:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-10 17:45 Chuck Ebbert [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-08-09  5:33 Masami Hiramatsu
2006-08-10  2:37 ` Frank Ch. Eigler
2006-08-10  4:15 ` Nicholas Miell
2006-08-21  1:58   ` Masami Hiramatsu
2006-08-31 17:52 ` Frank Ch. Eigler
2006-09-01  2:55   ` Masami Hiramatsu
2006-09-01 13:53     ` Frank Ch. Eigler

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=200608101343_MC3-1-C7B1-9E82@compuserve.com \
    --to=76306.1226@compuserve.com \
    --cc=haoki@redhat.com \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=soshima@redhat.com \
    --cc=systemtap@sourceware.org \
    --cc=yumiko.sugita.yf@hitachi.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).