Hi, my apologies for being terse, I'm in a meeting. On Mon, Oct 01 2018, Qing Zhao wrote: > Hi, Martin, > > I have studied a little more on > > https://github.com/marxin/kgraft-analysis-tool/blob/master/README.md <https://github.com/marxin/kgraft-analysis-tool/blob/master/README.md> > > in the Section “Usages”, from the example, we can see: > > the tool will report a list of affected functions for a function that will be patched. > In this list, it includes all callers of the patched function, and the cloned functions from the patched function due to ipa const-propogation or ipa sra. > > My question: > > what’s the current action to handle the cloned functions from the > patched function due to ipa const-proposation or ipa sra, etc? If we want to patch an inlined, cloned, or IPA-SRAed function, we also patch all of its callers. > > since those cloned functions are NOT in the source code level, how to generate the patches for the cloned functions? how to guarantee that after > the patched function is changed, the same ipa const-propogation or ipa > sra will still happened? You don't. Martin > > a little confused here. > > thanks. > > Qing >> On Sep 27, 2018, at 7:19 AM, Martin Jambor <mjambor@xxxxxxx> wrote: >> >> Hi, >> >> (this message is a part of the thread originating with >> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01018.html) >> >> On Thu, Sep 27 2018, Jan Hubicka wrote: >>>>> If you make this to be INTERPOSABLE (which means it can be replaced by different >>>>> implementation by linker and that is probably what we want for live patching) >>>>> then also inliner, ipa-sra and other optimization will give up on these. >>>> >>>> do you suggest that to set the global function as AVAIL_INTERPOSABLE when -finline-only-static >>>> is present? then we should avoid all issues? >>> >>> It seems to be reasonable direction I think, because it is what really happens >>> (well AVAIL_INTERPOSABLE still does not assume that the interposition will >>> happen at runtime, but it is an approximation and we may introduce something like >>> AVAIL_RUNTIME_INTERPOSABLE if there is need for better difference). >>> I wonder if -finline-only-static is good name for the flag though, because it >>> does a lot more than that. Maybe something like -flive-patching? >>> How much is this all tied to one particular implementation of the feature? >> >> We have just had a quick discussion with two upstream maintainers of >> Linux kernel live-patching about this and the key points were: >> >> 1. SUSE live-patch creators (and I assume all that use the upstream >> live-patching method) use Martin Liska's (somewhat under-documented) >> -fdump-ipa-clones option and a utility he wrote >> (https://github.com/marxin/kgraft-analysis-tool) to deal with all >> kinds of inlining, IPA-CP and generally all IPA optimizations that >> internally create a clone. The tool tells them what happened and >> also lists all callers that need to be live-patched. >> >> 2. However, there is growing concern about other IPA analyses that do >> not create a clone but still affect code generation in other >> functions. Kernel developers have identified and disabled IPA-RA but >> there is more of them such as IPA-modref analysis, stack alignment >> propagation and possibly quite a few others which extract information >> from one function and use it a caller or perhaps even some >> almost-unrelated functions (such as detection of read-only and >> write-only static global variables). >> >> The kernel live-patching community would welcome if GCC had an option >> that could disable all such optimizations/analyses for which it >> cannot provide a list of all affected functions (i.e. which ones need >> to be live-patched if a particular function is). >> >> I assume this is orthogonal to the proposed -finline-only-static >> option, but the above approach seems superior in all respects. >> >> 3. The community would also like to be involved in these discussions, >> and therefore I am adding live-patching@xxxxxxxxxxxxxxx to CC. On a >> related note, they will also have a live-patching mini-summit at the >> Linux Plumbers conference in Vancouver in November where they plan to >> discuss what they would like GCC to provide. >> >> Thanks, >> >> Martin >>
