On Wed, 2 Nov 2016, Jiri Kosina wrote: > Hi, > > the notes I've taken during the sessions today are below. They are > verbatim as taken during the session, please apologize any odd > formulations or typos you encounter. > > Please don't forget to upload your slides to the LPC webpage; you should > be able to attach them to your proposal. Alternatively, just send them to > me via e-mail and I'll add them there. > > Thanks! > > ========== > > 1) gcc optimizations > > gcc makes different optimizations during compilation. Depending how > the patches are being prepared, this might or might not be a problem. > As of gcc 6.2, the especially problematic ones seem to be: > > - inlining; solution: patch callers > - partial inlining > - IPA-SRA: removal of unused parameters, passing by reference -> > passing by value; basically violates ABI. Fortunately, gcc changes > the name of function (-> easily detectable) > - IPA-CP: even several clones of a function are possible if a set is limited > again, function name is changed again by gcc > - IPA-PURE-CONST: calls to such functions might be completely eliminated > - IPA-ICF: can merge different functions to unified one > - dead code elimination: after patch the code wouldn't be dead any more > solution: patch the callers as well > - IPA-RA: gcc optimizes the saving and restoring registers if it > considers it safe; we should probably disabled > > 2) Module creation tooling > > Current aproaches are kpatch-build (out-of-tree) and kbuild (in-tree). > > kpatch-build is based on comparing binary objects before and after applying > the patch. It has quite a few drabacks though (a lot of internal knowledge > of gcc and kernel is required to handle it properly -- altinstructions, > exception tables, switch statement jump tables, static local variables, etc). > Plus it's a maintainance nightmare. > > kbuild-based aproach is based on providing a new whole reimplementation > of the function in a kernel module and register it with klp API. > One of the main drawbacks is dealing with non-exported symbols. The current > workardound is to perform kallsyms lookup on the symbol, but that has its > own issues (error prone, doesn't use the relocation sections). > > Proposal (sent as RFC last week) is a new tool on top of the kbuild-based > aproach (klp-convert) that will be run to post-process the linked .ko and > generate proper relovation entries. > Improvements that would need to be done on top would be > > - support for altinstructions (we may need to change klp API for that) > - warning on unresolved symbols > - automatically detect and convert all relocations (all unresolved > relocations in the module) > - automatically detect and warn about gcc optimizations > > Chris O'Donell brought up a pending gcc modification (in the form of plugin) > that will contain range-based information about the optimizations that were > performed while generating the code; which would be very helpful for our > use case as well. Carlos, do you currently have anything you can share with us? Thanks a lot, Miroslav -- 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
