From owner-svn-src-head@freebsd.org Sun Mar 19 02:25:35 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DA7ED08B64; Sun, 19 Mar 2017 02:25:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 58FAE113B; Sun, 19 Mar 2017 02:25:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 5E9D34287AD; Sun, 19 Mar 2017 13:04:51 +1100 (AEDT) Date: Sun, 19 Mar 2017 13:04:50 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ed Maste cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r315522 - in head: contrib/binutils/ld/emulparams sys/conf In-Reply-To: <201703190022.v2J0MDhq015941@repo.freebsd.org> Message-ID: <20170319123107.W994@besplex.bde.org> References: <201703190022.v2J0MDhq015941@repo.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=_0Hqu8SF-oPYoeWnVvAA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 02:25:35 -0000 On Sun, 19 Mar 2017, Ed Maste wrote: > Log: > use INT3 instead of NOP for x86 binary padding > > We should never end up executing the inter-function padding, so we > are better off faulting than silently carrying on to whatever function > happens to be next. > > Note that LLD will soon do this by default (although it currently pads > with zeros). > > Reviewed by: dim, kib > MFC after: 1 month > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D10047 Is this a pessimization? Instruction prefetch near the end of almost every function now fetches INT3 instead of NOP. Both have to be decoded to decoded whether to speculatively execute them. INT3 is unlikely to be speculatively executed, but it takes extra work to decide not to do so. Functions normally end with a RET or unconditional JMP, and then branch prediction usually prevents speculative execution beyond the end, so the pessimization must be small. Intra-function padding that is executed now uses "fat NOP" instructions like null LEA's since this is faster to execute than a long string of NOPs. This is less readable than NOPs or even INT3's. Of course, INT3 can't be used for executed padding. I think it is also used for intra- function padding that is not executed. This is just harder to read unless it is needed to avoid the possible pessimization in this commit. The intra-function code with nops might look like: jmp over nop # 7 nops altogether nop over: or jmp over nullpad7 # single 7 byte null padding instruction over: and it is likely to be CPU-dependent whether 7 possibly-speculatively executed nops take more or less resources than 1 possibly-speculatively executed fancy instruction. I would expect the fancy instructions to take more resources each. Fancy LEAs don't seem such a good choice for executed padding either. amd64 uses lots of REX prefixes instead of fancy instructions, since these are designed to have low overheads. They certainly aren't executed separately. On i386, the same technique with lots of older prefixes is not used much, probably because all prefixes have high overheads on old i386's. They can be as slow as NOPs although they aren't executed separately. Bruce