On Tue, May 9, 2017 at 7:58 AM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > On Tue, May 09, 2017 at 03:00:45AM -0700, hpa@xxxxxxxxx wrote: >> I'm, ahem, highly skeptical to creating our own unwinding data format >> unless there is *documented, supported, and tested* way to force the >> compiler to *automatically* fall back to frame pointers any time there >> may be complexity involved, which at a very minimum includes any kind >> of data-dependent manipulation of the stack pointer. > > That would be nice. But isn't falling back to a frame pointer (or > another callee-saved reg or a stack location) already needed in such > cases? Otherwise how could DWARF unwinding work? > >> Otherwise you will have to fail the kernel build when your static tool >> runs into instruction sequences it can't deal with, but the compiler >> may generate them - boom. > > Failing the build is harsh, we could just warn about it and skip the > data for the affected function(s). > > BTW, there is another option. Instead of generating the data from > scratch, we could just convert gcc's DWARF CFI to the format we need. > > However that wouldn't solve the problems we have with the holes and > inaccuracies in DWARF from our hand-annotated asm, inline asm, and > special sections (extable, alternatives, etc). We'd still have to rely > on objtool for that, so we'd still be in the same boat of needing > objtool to be able to follow gcc code paths. CFI directives are documented in GNU assembler manual. They store unwind info in .eh_frame section. They work well with assembly codes in glibc. But I don't know how well they work with kernel unwind. > So yes, it sucks that objtool needs to work for unwinding to work. But > if we want decent DWARF-esque unwinding, I don't see any way around > that due to the low-level nature of the kernel. > >> Worse, your tool will not even recognize the problem and you're in a >> worse place than when you started. > > We could have a runtime NMI-based stack checker which ensures it can > always unwind to the bottom of the stack. Over time this would > hopefully provide full validation of the unwinder data and > functionality. > > -- > Josh -- H.J. -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
