On Tue, Jun 2, 2015 at 7:46 AM, Josh Poimboeuf <jpoim...@redhat.com> wrote: > On Tue, Jun 02, 2015 at 07:57:06AM +0200, Ingo Molnar wrote: >> * Andy Lutomirski <l...@amacapital.net> wrote: >> > On Mon, Jun 1, 2015 at 12:45 PM, Josh Poimboeuf <jpoim...@redhat.com> >> > wrote: >> > > On Fri, May 29, 2015 at 10:47:31AM -0700, Andy Lutomirski wrote: >> > >> 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). >> > >> > It might be nice to be able to reliably unwind out from an exception / >> > interrupt >> > / syscall frame into userspace or into the kernel code that trapped, >> > complete >> > with registers. >> > >> > In any event, we'll almost certainly have to manually annotate these weird >> > types >> > of entries. I wonder if we could manage to annotate just the entry parts >> > and >> > let a magic script do the rest. >> >> Even the entry parts we could help without uglifying the code: >> >> - either by adding a 'RET' instruction after IRET/SYSRET/SYSEXIT/etc. that >> the >> tooling can recognize as 'return from function'. That's much nicer than >> ugly >> annotations. >> >> - enhancing the tooling script to also recognize these instructions as >> function >> returns - because they _are_ function returns. > > I think the problem with the entry code (and other non-function asm > code) is that it's quite spaghetti-esque, with lots of jumps, returns, > calls, etc to random places. There aren't enough constraints which > would help the tooling make sense of where execution begins and ends, > when registers are saved or trashed, etc. > > Maybe over time we can figure out what constraints (and/or annotations) > are needed there. >
We can also try to reduce the spaghetti, which I'm working on. (It's even harder than I expected, and I doubt that any of my code will be ready for 4.2.) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
