Date: Sat, 23 Jul 2016 13:28:00 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Justin Hibbits <jhibbits@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r303209 - head/sys/powerpc/booke Message-ID: <20160723130540.Q2164@besplex.bde.org> In-Reply-To: <201607230227.u6N2Rgiw002223@repo.freebsd.org> References: <201607230227.u6N2Rgiw002223@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 Jul 2016, Justin Hibbits wrote: > Log: > Use label math instead of hard-coding offsets for return addresses. > > Though the chances of the code in these sections changing are low, future-proof > the sections and use label math. Not with numeric labels. > Renumber the surrounding areas to avoid duplicate label numbers. New numeric labels tend to move the addresses of old labels. Renumbering to give unique numeric labels more than defeats their reason for existence -- you have to manage them on every change to a label anywhere in the file (and perhaps in macros and included files). You never get a error for a duplicated numeric label. Non-unique numeric labels are also a good obfuscation. Given a branch to 1f or 1b, grepping the file for 1: may find many labels 1:. You have to examine all the labels named 1: or search only near the jump to see where 1 is. Its name is supposed to not matter, but perhaps it does. Numeric labels should only be used in macros, and then only when the macro processor is too feeble to support generating unique non-numeric labels. Standard cpp is too feeble for this. I managed to remove all numeric labels in i386/exception.s (except in macros and included files), and none came back. amd64/exception.S has 19 of them, 7 with the additional style bug of being on a line with a statement or comment. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160723130540.Q2164>