From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@linux.intel.com>,
Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>, gcc <gcc@gcc.gnu.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
David Daney <ddaney.cavm@gmail.com>,
Behan Webster <behanw@converseincode.com>,
Peter Zijlstra <peterz@infradead.org>,
Herbert Xu <herbert@gondor.hengli.com.au>
Subject: Re: [RFC] gcc feature request: Moving blocks into sections
Date: Mon, 5 Aug 2013 17:28:55 -0400 [thread overview]
Message-ID: <20130805212855.GA23044@Krystal> (raw)
In-Reply-To: <CA+55aFwrxRr4+kN8t8HCRnnVQyur5EGzQ_bRdYK3T-KW9Zp0aw@mail.gmail.com>
* Linus Torvalds (torvalds@linux-foundation.org) wrote:
> On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
> >
> > I remember that choosing between 2 and 5 bytes nop in the asm goto was
> > tricky: it had something to do with the fact that gcc doesn't know the
> > exact size of each instructions until further down within compilation
>
> Oh, you can't do it in the coompiler, no. But you don't need to. The
> assembler will pick the right version if you just do "jmp target".
Yep.
Another thing that bothers me with Steven's approach is that decoding
jumps generated by the compiler seems fragile IMHO.
x86 decoding proposed by https://lkml.org/lkml/2012/3/8/464 :
+static int make_nop_x86(void *map, size_t const offset)
+{
+ unsigned char *op;
+ unsigned char *nop;
+ int size;
+
+ /* Determine which type of jmp this is 2 byte or 5. */
+ op = map + offset;
+ switch (*op) {
+ case 0xeb: /* 2 byte */
+ size = 2;
+ nop = ideal_nop2_x86;
+ break;
+ case 0xe9: /* 5 byte */
+ size = 5;
+ nop = ideal_nop;
+ break;
+ default:
+ die(NULL, "Bad jump label section (bad op %x)\n", *op);
+ __builtin_unreachable();
+ }
My though is that the code above does not cover all jump encodings that
can be generated by past, current and future x86 assemblers.
Another way around this issue might be to keep the instruction size
within a non-allocated section:
static __always_inline bool arch_static_branch(struct static_key *key)
{
asm goto("1:"
"jmp %l[l_yes]\n\t"
"2:"
".pushsection __jump_table, \"aw\" \n\t"
_ASM_ALIGN "\n\t"
_ASM_PTR "1b, %l[l_yes], %c0 \n\t"
".popsection \n\t"
".pushsection __jump_table_ilen \n\t"
_ASM_PTR "1b \n\t" /* Address of the jmp */
".byte 2b - 1b \n\t" /* Size of the jmp instruction */
".popsection \n\t"
: : "i" (key) : : l_yes);
return false;
l_yes:
return true;
}
And use (2b - 1b) to know what size of no-op should be used rather than
to rely on instruction decoding.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2013-08-05 21:28 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 16:55 [RFC] gcc feature request: Moving blocks into sections Steven Rostedt
2013-08-05 17:02 ` H. Peter Anvin
2013-08-05 17:24 ` Steven Rostedt
2013-08-05 17:12 ` Linus Torvalds
2013-08-05 17:15 ` Linus Torvalds
2013-08-05 17:55 ` Steven Rostedt
2013-08-05 18:11 ` Steven Rostedt
2013-08-05 18:17 ` H. Peter Anvin
2013-08-05 18:23 ` Steven Rostedt
2013-08-05 18:29 ` H. Peter Anvin
2013-08-05 18:49 ` Steven Rostedt
2013-08-05 18:51 ` H. Peter Anvin
2013-08-05 19:01 ` Linus Torvalds
2013-08-05 19:54 ` Mathieu Desnoyers
2013-08-05 19:57 ` Linus Torvalds
2013-08-05 20:02 ` Steven Rostedt
2013-08-05 21:28 ` Mathieu Desnoyers [this message]
2013-08-05 21:43 ` H. Peter Anvin
2013-08-06 4:14 ` Mathieu Desnoyers
2013-08-06 4:28 ` H. Peter Anvin
2013-08-06 16:15 ` Steven Rostedt
2013-08-06 16:19 ` H. Peter Anvin
2013-08-06 16:26 ` Steven Rostedt
2013-08-06 16:29 ` H. Peter Anvin
2013-08-05 21:44 ` Steven Rostedt
2013-08-05 22:08 ` Mathieu Desnoyers
2013-08-05 19:09 ` Steven Rostedt
2013-08-05 18:20 ` Linus Torvalds
2013-08-05 18:24 ` Linus Torvalds
2013-08-05 18:34 ` Linus Torvalds
2013-08-05 18:38 ` H. Peter Anvin
2013-08-05 19:04 ` Steven Rostedt
2013-08-05 19:40 ` Marek Polacek
2013-08-05 19:56 ` Linus Torvalds
2013-08-05 19:57 ` Jason Baron
2013-08-05 20:35 ` Richard Henderson
2013-08-06 2:26 ` Jason Baron
2013-08-06 3:03 ` Steven Rostedt
2013-08-05 18:33 ` H. Peter Anvin
2013-08-05 18:39 ` Steven Rostedt
2013-08-05 18:49 ` Linus Torvalds
2013-08-05 19:39 ` Steven Rostedt
2013-08-06 14:19 ` Steven Rostedt
2013-08-06 17:48 ` Linus Torvalds
2013-08-06 17:58 ` Steven Rostedt
2013-08-06 20:33 ` Mathieu Desnoyers
2013-08-06 20:43 ` Steven Rostedt
2013-08-07 0:45 ` Steven Rostedt
2013-08-07 0:56 ` Steven Rostedt
2013-08-07 5:06 ` Ondřej Bílka
2013-08-07 15:02 ` Steven Rostedt
2013-08-07 16:03 ` Mathieu Desnoyers
2013-08-07 16:11 ` Steven Rostedt
2013-08-07 23:22 ` Mathieu Desnoyers
2013-08-05 20:06 ` Jason Baron
2013-08-05 19:04 ` Andi Kleen
2013-08-05 19:16 ` Steven Rostedt
2013-08-05 19:30 ` Xinliang David Li
2013-08-05 19:25 ` Linus Torvalds
2013-08-12 9:17 ` Peter Zijlstra
2013-08-12 14:56 ` H. Peter Anvin
2013-08-12 16:02 ` Andi Kleen
2013-08-12 16:11 ` Peter Zijlstra
2013-08-12 16:09 ` Peter Zijlstra
2013-08-12 17:47 ` H. Peter Anvin
2013-08-13 7:50 ` Peter Zijlstra
2013-08-13 14:46 ` H. Peter Anvin
2013-08-13 14:52 ` Steven Rostedt
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=20130805212855.GA23044@Krystal \
--to=mathieu.desnoyers@efficios.com \
--cc=behanw@converseincode.com \
--cc=ddaney.cavm@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=herbert@gondor.hengli.com.au \
--cc=hpa@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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