Re: [PATCH] x86/debug: Remove perpetually broken, unmaintainable dwarf annotations

[Josh Poimboeuf]

On Tue, Jun 02, 2015 at 07:57:06AM +0200, Ingo Molnar wrote:
> * Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> > On Mon, Jun 1, 2015 at 12:45 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> 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.


-- 
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/