[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150529213956.GA9869@redhat.com>
Date: Fri, 29 May 2015 17:39:56 -0400
From: "Frank Ch. Eigler" <fche@...hat.com>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Andy Lutomirski <luto@...capital.net>,
Ingo Molnar <mingo@...nel.org>,
Jan Beulich <JBeulich@...e.com>,
Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...e.hu>, Brian Gerst <brgerst@...il.com>,
Frédéric Weisbecker <fweisbec@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Denys Vlasenko <dvlasenk@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Dave Anderson <anderson@...hat.com>, x86@...nel.org
Subject: Re: [PATCH] x86/debug: Remove perpetually broken, unmaintainable dwarf annotations
Hi -
On Fri, May 29, 2015 at 03:27:16PM -0500, Josh Poimboeuf wrote:
> [...]
> > > Also, with the feature missing completely, maybe someone finds a method to
> > > introduce it in a maintainable fashion, while with the feature included upstream
> > > there's very little pressure to do that. As a bonus we'd also win a workable dwarf
> > > unwinder.
> >
> > Before doing something drastic like this, I think we should get Josh's
> > opinion, since I think he's working on a new (?) unwinder.
>
> I'd definitely like to replace all the asm DWARF CFI annotations with
> something more automated and robust. So it doesn't really affect me
> whether they're ripped out now or replaced later.
> [...]
> Then again, I'm not sure how useful or reliable the existing annotations
> are anyway, so maybe it doesn't matter much.
In our experience as consumers of this CFI information for years in
systemtap, the annotations have been generally correct and reliable.
Their presence allows reliable, correct, and efficient
kernel->userspace backtracing as used in important systemtap scripts.
If the current complaint is primarily about testability, it would be
easy to add simple stap-based tests to the kernel to exercise the code
and confirm its operation. Perhaps we could extract a specialized
self-contained test case (containing an unwinder).
I'm not in a position to judge the purported cost savings of removing
this code, but there is definitely a negative benefit as a loss of
useful functionality, esp. with no replacement in sight.
- FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists