Date:	Mon, 1 Jun 2015 14:45:16 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	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>,
	"Frank Ch. Eigler" <fche@...hat.com>
Subject: Re: [PATCH] x86/debug: Remove perpetually broken, unmaintainable
 dwarf annotations

On Fri, May 29, 2015 at 10:47:31AM -0700, Andy Lutomirski wrote:
> On Thu, May 28, 2015 at 6:17 AM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > * Jan Beulich <JBeulich@...e.com> wrote:
> >
> >> > and meanwhile you can keep a revert of this patch ported to SUSE kernels in
> >> > whatever fashion you prefer.
> >>
> >> Funny suggestion - I don't think that's reasonable for us to do. Or if we were
> >> to, we could as well invest in doing the re-work you're asking for; I don't
> >> think anyone will have the time to do either.
> >
> > That's fair enough: if there's not enough resources to keep a feature maintainable
> > upstream then it should not be upstream in that form.
> >
> > This isn't just some driver we can let bit-rot in peace until it finds a
> > maintainer (or not), without affecting anyone but users of that driver.
> >
> > This is hundreds of usage sites of ugly code intermixed with critical pieces of
> > assembly code that negatively affects the hackability of everything.
> >
> > 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.
> 
> FWIW, musl is considering some kind of automatic annotation scheme:
> 
> http://www.openwall.com/lists/musl/2015/05/13/5

Thanks for the link!  I found a newer version of it here:

  http://www.openwall.com/lists/musl/2015/05/31/5

Overall I think that script is a really good solution.

>From what I can tell, it tracks the CFA (stack pointer) perfectly.
(Which is actually pretty straightfoward if you just hook into function
entry/exit, push/pop, and add/sub to rsp).

It also does a nice job at making a best effort at tracking the caller's
register values (which are less important than CFA but still nice to
have).

Overall I'd bet that it would produce much more accurate results than
our current manual annotations.

I'm not crazy about the fact that it relies on awk, but I can't think of
a less hacky way to do that, without stuffing the CFI metadata directly
into the binary.

We could pretty easily port something like that to the kernel.  Before
that though, I think we'll need my stack validation patch set which
helps enforce asm function/non-function boundaries and proper ELF
function annotations.  Wrapping up a new version of that now.

-- 
Josh
--
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