Page MenuHomeFreeBSD

Build debug kernels with -O2.
ClosedPublic

Authored by trasz on Sep 17 2020, 8:44 PM.

Details

Summary

We've been building debug kernels (with 'makeoptions DEBUG=-g') with -O instead of -O2 ever since r140400. The original reason for that disappeared long ago, and plain -O on architectures other than amd64 leads to severe performance consequences, due to eg. disabling function inlining.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

trasz requested review of this revision.Sep 17 2020, 8:45 PM

Will this screw up the tracebacks? One of the reason that I've compiled at lower O levels is to not have @#^#$Y up DEBUG kernels...

In D26471#588937, @imp wrote:

Will this screw up the tracebacks? One of the reason that I've compiled at lower O levels is to not have @#^#$Y up DEBUG kernels...

I'll try to experiment under QEMU. My guess is they will be fine, although I do most work on amd64 (which is built -O2 even for debug kernels) and MIPS, and on MIPS ddb whas often broken anyway.

jrtc27 added inline comments.
sys/conf/kern.pre.mk
56–64 ↗(On Diff #77160)
In D26471#588937, @imp wrote:

Will this screw up the tracebacks? One of the reason that I've compiled at lower O levels is to not have @#^#$Y up DEBUG kernels...

-O was -O2 in GCC and Clang (and documented as such) for many years until the latest releases, so this is more keeping the status quo rather than regressing performance due to compiler defaults changing. Also amd64 already forces -O2 so (recently) got an "unfair" performance boost over other architectures (or more accurately didn't get a performance regression), yet most debugging time is likely spent on amd64 kernels due to its sheer popularity.

Apply suggestion from Jess (if I understood it correctly).

+1 from the PowerPC camp here.

Theoretically, -g and the ability of symbols should be enough to allow for debugging to work, even for stuff that has been inlined, as the fact that the inlining has happened is recorded in the debug data.

Possibly adding -fno-omit-frame-pointer may help an additional bit with debugging on platforms that don't normally use frame pointers, but that doesn't really have anything to do directly with inlining. (It's more about locals tracking, really)

This seems fine but please make sure you mention that llvm11 changed -O to -O1 whereas it was -O2 before so this is just keeping the previous opt level for llvm and only changes things if you compile with GCC.

This revision was not accepted when it landed; it landed in state Needs Review.Tue, Sep 29, 11:48 AM
Closed by commit rS366251: Build debug kernels with -O2. (authored by trasz). · Explain Why
This revision was automatically updated to reflect the committed changes.
head/sys/conf/kern.pre.mk
62–64

Hmm, -O wouldn't hit this case for non-x86 (and non-powerpc) before I believe, but now does. If ports have been happy running at -O without -fno-strict-aliasing, i.e. using -O2 without it when using Clang 10 and below, do we still need this?