svn commit: r296428 - head/sys/boot/common

[Dimitry Andric]

On 07 Mar 2016, at 19:50, Warner Losh <imp at bsdimp.com> wrote:
> 
>> On Mar 7, 2016, at 10:41 AM, Dimitry Andric <dim at freebsd.org> wrote:
>> 
>> On 07 Mar 2016, at 17:28, Warner Losh <imp at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20160307/9edbb398/attachment.sig>