Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 2 Jun 2015 10:00:24 -0700 | Subject | Re: [PATCH] x86/debug: Remove perpetually broken, unmaintainable dwarf annotations |
| |
On Tue, Jun 2, 2015 at 7:46 AM, Josh Poimboeuf <jpoimboe@redhat.com> wrote: > On Tue, Jun 02, 2015 at 07:57:06AM +0200, Ingo Molnar wrote: >> * Andy Lutomirski <luto@amacapital.net> wrote: >> > On Mon, Jun 1, 2015 at 12:45 PM, Josh Poimboeuf <jpoimboe@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
| |