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 stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html