Date: Mon, 7 Mar 2016 19:59:05 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r296428 - head/sys/boot/common Message-ID: <E3943FC6-896A-4CC3-8AD9-CA6B32A39CE0@FreeBSD.org> In-Reply-To: <10F1E4F3-BE8A-4BC3-AFC3-FB4C3A729B60@bsdimp.com> References: <201603061557.u26FvhMi033982@repo.freebsd.org> <56DCD52F.4010709@freebsd.org> <AC0A9708-B618-4D05-8532-BD451AB94A60@FreeBSD.org> <1457365187.13785.174.camel@freebsd.org> <20160307155217.GJ67250@kib.kiev.ua> <CANCZdforb7gAanu4Hys6b2NmhOGVGn7UutsUqav5gGUsqSTMxA@mail.gmail.com> <C6FFFB5D-EAE1-4BFA-90EC-6AE2DF67A921@FreeBSD.org> <10F1E4F3-BE8A-4BC3-AFC3-FB4C3A729B60@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_7E485799-7391-4A68-A51D-7CE30DCA1055 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 07 Mar 2016, at 19:50, Warner Losh <imp@bsdimp.com> wrote: >=20 >> On Mar 7, 2016, at 10:41 AM, Dimitry Andric <dim@freebsd.org> wrote: >>=20 >> On 07 Mar 2016, at 17:28, Warner Losh <imp@bsdimp.com> wrote: >> ... >>> Alternatively, is there a switch to clang 3.8 that says 'Don't = generate the new >>> relocation, use the old one instead" which would also be safe and = allow a >>> less-bumpy transition? >>=20 >> On amd64, we actually compile source files for the kernel with >> -fno-asynchronous-unwind-tables, which is the flag that ensures = object >> files do not end up with a .eh_frame section, because the compiler = will >> refrain from inserting CFI directives into the assembler. >=20 > Excellent. >=20 >> However, this only affects C source files, and we have a number of >> hand-written assembler sources in the tree, with CFI directives in = them. >> These will always result in .eh_frame sections, unless there is = another >> assembler-specific flag of suppressing that. >=20 > what are the odds of fixing this? Since the vast majority of assembler = code > is going to be in the base kernel. The AESNI stuff is the only = exception > that I can think of=E2=80=A6 >=20 > Are the CFI directives so that DTRACE works, or is there some other = reason? You could comment out the directives, but these are really the standard way to do unwinding on amd64, without having to follow stack frames 'manually'. It would even be better to drop the -fno-asynchronous-unwind-tables option, and actually start making use of the unwind information in e.g. the kernel debugger, or even for producing crash backtraces. -Dimitry --Apple-Mail=_7E485799-7391-4A68-A51D-7CE30DCA1055 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlbdz30ACgkQsF6jCi4glqOcpwCfcewuixxByOa82gFJ2Lwb6w0Y OtwAn2hcKVVUg+6sTshEXAu+FGLkhaIV =9u4l -----END PGP SIGNATURE----- --Apple-Mail=_7E485799-7391-4A68-A51D-7CE30DCA1055--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E3943FC6-896A-4CC3-8AD9-CA6B32A39CE0>