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.

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.

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