public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Baron <jbaron@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>, Andi Kleen <ak@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: Immediate values
Date: Thu, 24 Sep 2009 11:39:01 -0400	[thread overview]
Message-ID: <20090924153900.GB2648@redhat.com> (raw)
In-Reply-To: <4ABB7F58.5030508@zytor.com>

On Thu, Sep 24, 2009 at 07:16:56AM -0700, H. Peter Anvin wrote:
> Jason Baron wrote:
>>
>> http://marc.info/?l=linux-kernel&m=125200966226921&w=2
>>
>> The basic idea is that gcc, 4.5 will have support for an 'asm goto'
>> construct which can refer to c code labels. Thus, we can replace a nop
>> in the code stream with a 'jmp' instruction to various branch targets.
>>
>
> Looking at the above, I'm a bit unclear for the need for a NOP5.  We  
> obviously need a *total* of 5 bytes, but at least I don't seem to  
> understand why we need 7 bytes per tracepoint.
>
> 	-hpa

that's right. The optimal solution doesn't require the the NOP5 at all,
and I've been playing around with an implementation that doesn't have
it. The problem I've been running into is that sometimes the compiler
will put in a short jump - '0xeb', with a 1 byte offset, but the jump
target is further away. Thus, I need to either ensure the target is
close, or somehow force a longer jump '0xe9' into the code so I always
have the space. The other advantage of not including the nop is easier
support for all x86 implementations, since I'm not sure a 5 byte atomic
nop is always available, whereas a jump is always atomic. I'm pretty
sure we can come up with a patch that avoids the nop...I'll keep working
on it.

thanks,

-Jason

  reply	other threads:[~2009-09-24 15:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-24 12:31 Immediate values Mathieu Desnoyers
2009-09-24 12:34 ` Ingo Molnar
2009-09-24 14:02   ` Jason Baron
2009-09-24 14:10     ` H. Peter Anvin
2009-09-24 14:16     ` Mathieu Desnoyers
2009-09-24 19:16       ` Ingo Molnar
2009-09-24 19:34         ` Ingo Molnar
2009-09-25  6:51           ` Arjan van de Ven
2009-09-25  7:35             ` Mathieu Desnoyers
2009-09-25  8:25               ` Arjan van de Ven
2009-09-25 10:02               ` Alan Cox
2009-09-25 10:14                 ` Arjan van de Ven
2009-09-25 16:19                   ` H. Peter Anvin
2009-09-25 16:45                     ` Arjan van de Ven
2009-09-25 17:05                       ` H. Peter Anvin
2009-09-25 10:18                 ` Richard J Moore
2009-09-25 11:12                   ` Masami Hiramatsu
2009-09-24 14:16     ` H. Peter Anvin
2009-09-24 15:39       ` Jason Baron [this message]
2009-09-24 16:52         ` H. Peter Anvin

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=20090924153900.GB2648@redhat.com \
    --to=jbaron@redhat.com \
    --cc=ak@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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