Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler
From: Linus Torvalds
Date: Tue Aug 05 2014 - 12:49:24 EST
On Tue, Aug 5, 2014 at 4:31 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
>
> Sorry to bring this back up after the fact, but it's important for a
> number of things in various distros
You said that before, and I ignored you before, because you didn't
actually give any examples.
>. I don't disagree it should be
> disabled by default, but making it unconditional is going to force the
> distributions that care about perf, systemtap, and debuggers to
> manually revert this.
Bah. I bet I use 'perf' more than most, and it doesn't care about
debug info. Sure, if you want the annotated source code, or put probes
in place, you want the line number information, but the amount of
debug information it needs is miniscule, and not impacted bu this at
all afaik.
And systemtap people have more problems than this.
Debuggers? Again, people who actually use kgdb have bigger issues than
some slightly worse local variable tracking. People care about the
frame pointer information and type information, but if you use kgdb on
the kernel you can damn well look at the assembly code and source code
annotation for local variable information.
So I call bullshit. Give a real example of real-world use, not some
random handwaving of cases that happen to use debug info but - at
least for the kernel - don't actually care about the variable
tracking.
The variable tracking is absolutely the *least* important part of the
debug info. By a huge margin. To the point of being entirely
irrelevant for the kernel. You make it sound like you lose all debug
information, when in reality that's not the case at all.
Trust me, you lose *way* more debug information because the kernel
uses "-O2" rather than "-O".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/