On Wed, Aug 6, 2014 at 1:14 AM, Jakub Jelinek wrote:
> On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
d>> 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
>
> I have no problem with a
Jakub Jelinek writes:
> There have been several man-years of work to get from the 25% var coverage
> to 67%, several DWARF extensions (most of them to be available in DWARF5 or
> work in progress on that) and with -fno-var-tracking-assignments that is
> just returned to the old state.
This is a
On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
> On Tue, Aug 5, 2014 at 2:07 PM, Frank Ch. Eigler 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,
On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
On Tue, Aug 5, 2014 at 2:07 PM, Frank Ch. Eigler f...@redhat.com wrote:
Actually, perf probe does (via HAVE_DWARF_SUPPORT), to place probes
and to extract variables at those probes, much as systemtap does.
Without
Jakub Jelinek ja...@redhat.com writes:
There have been several man-years of work to get from the 25% var coverage
to 67%, several DWARF extensions (most of them to be available in DWARF5 or
work in progress on that) and with -fno-var-tracking-assignments that is
just returned to the old
On Wed, Aug 6, 2014 at 1:14 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
d 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
I have no problem with
On Tue, Aug 5, 2014 at 4:30 PM, Frank Ch. Eigler wrote:
>
> Would you consider a patch that does a gcc COMPARE_DEBUG-based test?
Yes. But as mentioned, we don't have a really good way to do that. I
guess we can do something similar to what "cc-option" does, but that
will end up doing it for
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
On Tue, Aug 5, 2014 at 2:07 PM, Frank Ch. Eigler 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
Hi -
> >>. 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
On Tue, Aug 5, 2014 at 12:49 PM, Linus Torvalds
wrote:
> On Tue, Aug 5, 2014 at 4:31 AM, Josh Boyer 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
>
On Tue, Aug 5, 2014 at 4:31 AM, Josh Boyer 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
>
On Tue, Aug 05, 2014 at 01:46:49PM +0200, Markus Trippelsdorf wrote:
> On 2014.08.05 at 07:31 -0400, Josh Boyer wrote:
> > Sorry to bring this back up after the fact, but it's important for a
> > number of things in various distros. I don't disagree it should be
> > disabled by default, but
On Tue, Aug 05, 2014 at 07:31:22AM -0400, Josh Boyer wrote:
> On Wed, Jul 30, 2014 at 11:47 AM, Linus Torvalds
> wrote:
> > On Tue, Jul 29, 2014 at 11:53 PM, Jakub Jelinek wrote:
> >>
> >> IMNSHO this is a too big hammer approach. The bug happened on a single
> >> file only (right?)
> >
> >
On 2014.08.05 at 07:31 -0400, Josh Boyer wrote:
> Sorry to bring this back up after the fact, but it's important for a
> number of things in various distros. I don't disagree it should be
> disabled by default, but making it unconditional is going to force the
> distributions that care about
On Wed, Jul 30, 2014 at 11:47 AM, Linus Torvalds
wrote:
> On Tue, Jul 29, 2014 at 11:53 PM, Jakub Jelinek wrote:
>>
>> IMNSHO this is a too big hammer approach. The bug happened on a single
>> file only (right?)
>
> Very dubious. We happened to see it in a single case, and _maybe_ that
> was
On Wed, Jul 30, 2014 at 11:47 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Jul 29, 2014 at 11:53 PM, Jakub Jelinek ja...@redhat.com wrote:
IMNSHO this is a too big hammer approach. The bug happened on a single
file only (right?)
Very dubious. We happened to see it in a
On 2014.08.05 at 07:31 -0400, Josh Boyer wrote:
Sorry to bring this back up after the fact, but it's important for a
number of things in various distros. I don't disagree it should be
disabled by default, but making it unconditional is going to force the
distributions that care about perf,
On Tue, Aug 05, 2014 at 07:31:22AM -0400, Josh Boyer wrote:
On Wed, Jul 30, 2014 at 11:47 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Jul 29, 2014 at 11:53 PM, Jakub Jelinek ja...@redhat.com wrote:
IMNSHO this is a too big hammer approach. The bug happened on a single
On Tue, Aug 05, 2014 at 01:46:49PM +0200, Markus Trippelsdorf wrote:
On 2014.08.05 at 07:31 -0400, Josh Boyer wrote:
Sorry to bring this back up after the fact, but it's important for a
number of things in various distros. I don't disagree it should be
disabled by default, but making it
On Tue, Aug 5, 2014 at 4:31 AM, Josh Boyer jwbo...@fedoraproject.org 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
On Tue, Aug 5, 2014 at 12:49 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Aug 5, 2014 at 4:31 AM, Josh Boyer jwbo...@fedoraproject.org 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
Hi -
. 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.
Actually,
On Tue, Aug 5, 2014 at 2:07 PM, Frank Ch. Eigler f...@redhat.com 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
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
On Tue, Aug 5, 2014 at 4:30 PM, Frank Ch. Eigler f...@redhat.com wrote:
Would you consider a patch that does a gcc COMPARE_DEBUG-based test?
Yes. But as mentioned, we don't have a really good way to do that. I
guess we can do something similar to what cc-option does, but that
will end up doing
On Tue, Jul 29, 2014 at 11:53 PM, Jakub Jelinek wrote:
>
> IMNSHO this is a too big hammer approach. The bug happened on a single
> file only (right?)
Very dubious. We happened to see it in a single case, and _maybe_ that
was the only one in the whole kernel. But it's much more likely that
it
On 2014.07.30 at 09:21 +0200, Jakub Jelinek wrote:
> On Wed, Jul 30, 2014 at 09:13:08AM +0200, Markus Trippelsdorf wrote:
> > On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote:
> > > On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> > > > 3.15-stable review patch. If anyone
On Wed, Jul 30, 2014 at 09:13:08AM +0200, Markus Trippelsdorf wrote:
> On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote:
> > On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> > > 3.15-stable review patch. If anyone has any objections, please let me
> > > know.
> >
> >
On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote:
> On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> > 3.15-stable review patch. If anyone has any objections, please let me know.
>
> IMNSHO this is a too big hammer approach. The bug happened on a single
> file only
On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
> 3.15-stable review patch. If anyone has any objections, please let me know.
IMNSHO this is a too big hammer approach. The bug happened on a single
file only (right?), so if anything, IMHO it could be disabled for that
single
On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
3.15-stable review patch. If anyone has any objections, please let me know.
IMNSHO this is a too big hammer approach. The bug happened on a single
file only (right?), so if anything, IMHO it could be disabled for that
single
On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote:
On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
3.15-stable review patch. If anyone has any objections, please let me know.
IMNSHO this is a too big hammer approach. The bug happened on a single
file only (right?), so
On Wed, Jul 30, 2014 at 09:13:08AM +0200, Markus Trippelsdorf wrote:
On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote:
On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
3.15-stable review patch. If anyone has any objections, please let me
know.
IMNSHO this is a
On 2014.07.30 at 09:21 +0200, Jakub Jelinek wrote:
On Wed, Jul 30, 2014 at 09:13:08AM +0200, Markus Trippelsdorf wrote:
On 2014.07.30 at 08:53 +0200, Jakub Jelinek wrote:
On Tue, Jul 29, 2014 at 06:49:09PM -0700, Greg Kroah-Hartman wrote:
3.15-stable review patch. If anyone has any
On Tue, Jul 29, 2014 at 11:53 PM, Jakub Jelinek ja...@redhat.com wrote:
IMNSHO this is a too big hammer approach. The bug happened on a single
file only (right?)
Very dubious. We happened to see it in a single case, and _maybe_ that
was the only one in the whole kernel. But it's much more
36 matches
Mail list logo
