Build debug kernels with -O2.
ClosedPublic
Actions

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

Details

Reviewers: None
Commits: rS366251: Build debug kernels with -O2.

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 - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

trasz created this revision.Sep 17 2020, 8:44 PM

Herald added a subscriber: imp. · View Herald TranscriptSep 17 2020, 8:45 PM

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

Harbormaster completed remote builds in B33617: Diff 77159.Sep 17 2020, 8:45 PM

trasz edited the summary of this revision. (Show Details)Sep 17 2020, 8:49 PM

Tweak.

Harbormaster completed remote builds in B33618: Diff 77160.Sep 17 2020, 9:12 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...

(Tinderboxed.)

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 a subscriber: jrtc27.Sep 18 2020, 3:14 PM

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).

Harbormaster completed remote builds in B33707: Diff 77332.Sep 21 2020, 10:23 PM

(Also tinderboxed.)

+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.Sep 29 2020, 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.

trasz added a commit: rS366251: Build debug kernels with -O2..

jrtc27 added inline comments.Sep 30 2020, 12:37 PM

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?