Explicitly set -O1 instead of -O2 for compatibility with gcc

[ngie]

Summary

Explicitly set -O1 instead of -O0 for compatibility with gcc

clang's -O implies -O2 whereas gcc's -O implies -O1. For the sake of
compatibility with gcc, set -O1 in the default CFLAGS

[emaste]

share/mk/sys.mk

55

This is most likely incorrect for arm. This change comes from rS173375:

Switch arm to -O until the -O2 issues are resolved.

Given that we've been building arm with Clang for some time, and it treats -O as -O2, it's probably fair to say the -O2 issues are resolved with Clang as the compiler.

[emaste]

share/mk/sys.mk

55

For reference, mips was added in rS177925

[emaste]

For arm at least it looks like the current behaviour is actually what we want: -O1 with gcc, -O2 with clang. Clang/mips isn't workable yet, but in any case I think it's probably best to leave this, but put a comment with an explanation like this.

[ngie]

In D2598#48241, @emaste wrote:

For arm at least it looks like the current behaviour is actually what we want: -O1 with gcc, -O2 with clang. Clang/mips isn't workable yet, but in any case I think it's probably best to leave this, but put a comment with an explanation like this.

What started me on this mini crusade was the fact that there's been some noise at $work about "how clang sucks" for debugging because it over aggressively optimizes things out. I did some digging and discovered that clang and gcc don't match up in terms of -O behavior, after I had to debug some kernel code with kgdb. Once I reduced the optimization level, debugging became useful (hence the proposed change).

I could remove the arm test in the conditional, or add a COMPILER_TYPE == gcc check to make sure that the -O value remains true to -O1 for gcc with arm/mips...

[emaste]

In D2598#48248, @ngie wrote:

What started me on this mini crusade was the fact that there's been some noise at $work about "how clang sucks" for debugging because it over aggressively optimizes things out. I did some digging and discovered that clang and gcc don't match up in terms of -O behavior, after I had to debug some kernel code with kgdb. Once I reduced the optimization level, debugging became useful (hence the proposed change).

I think that's a fair statement, and we likely want to provide a more obvious way to set -O1 for Clang for debugging, but I think that's not machine-dependent, and a separate change from this one.

I could remove the arm test in the conditional

I don't think that's right either, because I suspect building arm with in-tree GCC should continue to use -O1

or add a COMPILER_TYPE == gcc check to make sure that the -O value remains true to -O1 for gcc with arm/mips...

Maybe, but that just gives us the behaviour we already have?

[imp]

In D2598#48249, @emaste wrote:

In D2598#48248, @ngie wrote:

What started me on this mini crusade was the fact that there's been some noise at $work about "how clang sucks" for debugging because it over aggressively optimizes things out. I did some digging and discovered that clang and gcc don't match up in terms of -O behavior, after I had to debug some kernel code with kgdb. Once I reduced the optimization level, debugging became useful (hence the proposed change).

I think that's a fair statement, and we likely want to provide a more obvious way to set -O1 for Clang for debugging, but I think that's not machine-dependent, and a separate change from this one.

I could remove the arm test in the conditional

I don't think that's right either, because I suspect building arm with in-tree GCC should continue to use -O1

or add a COMPILER_TYPE == gcc check to make sure that the -O value remains true to -O1 for gcc with arm/mips...

Maybe, but that just gives us the behaviour we already have?

Please, dear god, don't add a COMPILER_TYPE check to sys.mk. It isn't defined there, and adding bsd.compilers.mk there would be a great leap backwards. There's so many issues with that I can't even begin to enumerate them all. But it introduces a forced fork to determine the compiler type, which may not exist in the path and would kill the make there. And there will be many others. I tried playing whack-a-mole with this a while ago and there's a lot of moles to whack in environments that you likely don't have. It quite simply isn't possible to make it work, and the problem you are trying to solve is trivial in comparison to the pain you will introduce.

Also, the issue is more fundamental that just changing the default here. Making debugging useful, while a nice goal, takes a back seat in many environments to making things fast. Some sort of better design that would allow setting -O to different levels would be useful for that tiny sliver of the people that give a crap about debugging, while still allowing things to be faster for deployed systems.

[ngie]

In D2598#48265, @imp wrote:

In D2598#48249, @emaste wrote:

In D2598#48248, @ngie wrote:

What started me on this mini crusade was the fact that there's been some noise at $work about "how clang sucks" for debugging because it over aggressively optimizes things out. I did some digging and discovered that clang and gcc don't match up in terms of -O behavior, after I had to debug some kernel code with kgdb. Once I reduced the optimization level, debugging became useful (hence the proposed change).

I think that's a fair statement, and we likely want to provide a more obvious way to set -O1 for Clang for debugging, but I think that's not machine-dependent, and a separate change from this one.

I could remove the arm test in the conditional

I don't think that's right either, because I suspect building arm with in-tree GCC should continue to use -O1

or add a COMPILER_TYPE == gcc check to make sure that the -O value remains true to -O1 for gcc with arm/mips...

Maybe, but that just gives us the behaviour we already have?

Please, dear god, don't add a COMPILER_TYPE check to sys.mk. It isn't defined there, and adding bsd.compilers.mk there would be a great leap backwards. There's so many issues with that I can't even begin to enumerate them all. But it introduces a forced fork to determine the compiler type, which may not exist in the path and would kill the make there. And there will be many others. I tried playing whack-a-mole with this a while ago and there's a lot of moles to whack in environments that you likely don't have. It quite simply isn't possible to make it work, and the problem you are trying to solve is trivial in comparison to the pain you will introduce.

Also, the issue is more fundamental that just changing the default here. Making debugging useful, while a nice goal, takes a back seat in many environments to making things fast. Some sort of better design that would allow setting -O to different levels would be useful for that tiny sliver of the people that give a crap about debugging, while still allowing things to be faster for deployed systems.

Yowch. Yeah, my suggestion earlier this morning was not a good idea...

Would it make sense to repurpose COPTFLAGS from sys/conf/kern.pre.mk for userland so it could be used as the default -O* flags in the non-POSIX case?

Leaving POSIX alone with -O is desired for compliance with the OpenGroup docs: http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html

[ngie]

In D2598#48318, @ngie wrote:

...

Yowch. Yeah, my suggestion earlier this morning was not a good idea...

Would it make sense to repurpose COPTFLAGS from sys/conf/kern.pre.mk for userland so it could be used as the default -O* flags in the non-POSIX case?

And also, allow the end-user to override -O* for their liking so they could get as little or as much debugging as possible?

I'm still a bit torn on the default value in kernel space, but we can work that out in a little bit...

[ngie]

After doing some more digging, it turns out that -O1 with clang is basically useless for debugging in some situations, just like the base system copy of gcc: http://llvm.org/bugs/show_bug.cgi?id=23636 . gcc 4.8+ is another ball of wax.

Discarding this review :(.