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
[-- Attachment #1 --] On 07 Mar 2016, at 19:50, Warner Losh <imp@bsdimp.com> wrote: > >> On Mar 7, 2016, at 10:41 AM, Dimitry Andric <dim@freebsd.org> wrote: >> >> 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? >> >> 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. > > Excellent. > >> 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. > > 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… > > 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlbdz30ACgkQsF6jCi4glqOcpwCfcewuixxByOa82gFJ2Lwb6w0Y OtwAn2hcKVVUg+6sTshEXAu+FGLkhaIV =9u4l -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E3943FC6-896A-4CC3-8AD9-CA6B32A39CE0>