Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754581Ab3HEVnz (ORCPT ); Mon, 5 Aug 2013 17:43:55 -0400 Received: from mga02.intel.com ([134.134.136.20]:2282 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753916Ab3HEVny (ORCPT ); Mon, 5 Aug 2013 17:43:54 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.89,821,1367996400"; d="scan'208";a="382333979" Message-ID: <52001C92.3070209@linux.intel.com> Date: Mon, 05 Aug 2013 14:43:46 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mathieu Desnoyers CC: Linus Torvalds , Steven Rostedt , LKML , gcc , Ingo Molnar , Thomas Gleixner , David Daney , Behan Webster , Peter Zijlstra , Herbert Xu Subject: Re: [RFC] gcc feature request: Moving blocks into sections References: <1375725328.22073.101.camel@gandalf.local.home> <51FFEC56.6040206@linux.intel.com> <1375727010.22073.110.camel@gandalf.local.home> <51FFEEEC.5060902@linux.intel.com> <1375728583.22073.118.camel@gandalf.local.home> <51FFF430.1060701@linux.intel.com> <20130805195446.GA22359@Krystal> <20130805212855.GA23044@Krystal> In-Reply-To: <20130805212855.GA23044@Krystal> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1892 Lines: 56 On 08/05/2013 02:28 PM, Mathieu Desnoyers wrote: > * Linus Torvalds (torvalds@linux-foundation.org) wrote: >> On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers >> 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. > For unconditional jmp that should be pretty safe barring any fundamental changes to the instruction set, in which case we can enable it as needed, but for extra robustness it probably should skip prefix bytes. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/