Re: [PATCH 3.15 33/37] Fix gcc-4.9.0 miscompilation of load_balance() in scheduler
From: Frank Ch. Eigler
Date: Tue Aug 05 2014 - 19:32:07 EST
Hi -
On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
> > Actually, "perf probe" does (via HAVE_DWARF_SUPPORT), to place probes
> > and to extract variables at those probes, much as systemtap does.
> > Without var-tracking, probes placed at most interior points of
> > functions will make variables inaccessible.
>
> .. and as mentioned, -O2 already does that for many things, even
> *with* tracking.
The whole point of variable tracking was to make -O2 usable (though
still imperfect) for those who use debuggers and such tools.
> [...] I don't understand how you guys can be so cavalier about a
> compiler bug that has already resulted in actual real problems.
No one is minimizing the problem. We are looking for a knob for those
who know that their compiler does not have that bug. (Plus, those who
don't care about debug data could use CONFIG_DEBUG_INFO=n with the bad
compiler.)
> You bring up theoretical cases that nobody has actually reported
> [...]
I assure you that the years of effort that went into gcc variable
tracking was justified with actual reports.
> Do you compile without -O2 too? Because I *guarantee* you that with
> -O2 (even with tracking), you'll get "local variable 'xyz' optimized
> away" cases.
One gets many fewer than without it, and also fewer false positives
(where the non-var-tracking debuginfo claims a variable may be
available, but points to the wrong place).
> [...] Until you can get the compiler people to have some sane way
> to know the problem is gone, I'm not going to maintain a kernel that
> uses a known-broken compiler feature. It's that simple.
Would you consider a patch that does a gcc COMPARE_DEBUG-based test?
- FChE
--
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/