On Thu, 19 Oct 2017, Josh Poimboeuf wrote: > On Wed, Oct 11, 2017 at 09:42:09AM -0300, Joao Moreira wrote: > > > Sounds good! For klp-convert to be successful, we really need a > > > strategy for dealing with such optimizations. I'm thinking that a > > > '-fpreserve-function-abi' flag would be the cleanest way to handle it. > > > > > > If we don't have a strategy for dealing with optimizations, then we may > > > instead need to go with a binary diff-based tool like kpatch-build. > > > > I'm currently looking into binary diff-based solutions to deal with this > > problem. My plan is to submit a second patch set once I have it functional > > and land both things (klp-convert and bin-diff) in two different steps. > > Instead of having multiple approaches, I'd strongly prefer that we > converge on a single in-tree approach that works for everybody. > > (Whether that will be source-based like klp-convert or binary-based like > kpatch-build, I don't know.) I think that klp-convert can work with both. Even with non-source-based solution you need something to generate those relocation records. I consider klp-convert as a part of the building pipeline. > BTW, what is bin-diff? Have you seen kpatch-build? I'm speaking for Joao here, but we discussed this personally and I think he meant approach based on asmtool (https://github.com/joergroedel/asmtool). We'd like to explore as much as possible. We also considered complete source-based solution. Nicolai Stange works on that (or at least on something which would make it possible). We can decide what to have in upstream afterwards. But I still think that klp-convert will be part of it in some form. Am I missing something? > > Is there any issue with following this schedule? Meaning, do you guys still > > plan on reviewing this patch set or do you prefer me to do something > > differently in terms of approach? > > IMO, klp-convert will only be useful if we have a realistic strategy for > dealing with GCC optimizations. So I'd say we should follow through on > that with the compiler folks before spending too much more time on it. Yes, I'm all for a solution on GCC side, but that may take a while and even then it is still a huge step to get it into a distribution (we have GCC 4.8.5 in SLE12 :)). However, there is an easy temporary solution. You can add all referenced optimized functions to a livepatch and let klp-convert process the rest. 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
