> b) 100% reliable stack traces for DWARF enabled kernels > > This is not yet implemented. See Documentation/stack-validation.txt > for more details about what is planned. The automatic CFI generation tool seems like a bad idea to me. There's not that much assembler code in Linux, and often when new assembler code is added it is something tricky. In this case you may end up spending more time fixing the tool than just fixing the assembler. It would be also quite bad to require people who want to add some new assembler code to learn how to fix your tool to make their assembler work. It also wouldn't surprise me if there are some possible assembler tricks that are very hard/impossible to handle for a tool. For example how do you have alternative() style patching? (that's a generic problem with your approach BTW) Doing some kind of CFI verifier would seem more feasible, but it would need a black/white list to override it to handle the above cases. BTW how do handle the increasing number of JITs in the kernel? -Andi -- 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
