On Tue, Aug 5, 2014 at 2:07 PM, Frank Ch. Eigler <fche@xxxxxxxxxx> 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.
In other words, anybody who relies on it has already learnt to work
around it. Or, more likely, there just isn't anybody who relies on it.
I don't understand how you guys can be so cavalier about a compiler
bug that has already resulted in actual real problems. You bring up
theoretical cases that nobody has actually reported, and are
apparently ignoring the fact that the compiler generates INCORRECT
CODE. So on one hand we have known breakage, on the other we have
theoretical "I can make an example" arguments of behavior that no sane
user has ever done.
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.
Christ.
I have asked the compiler people at least twice whether there is some
way to limit it to just gcc-4.9.0/1, but the compiler people didn't
step up and say that it was safe.
In the meantime, crazy people can choose to compile with known-broken
compilers. 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.
Linus
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html