Thanks, Martin, for all these interesting information. Looks like that a more general option to help live-patching is needed. I will do a little more study on this direction. 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 > > ... >>>>> >>>>>> For example comdat that was cloned by IPA-SRA. See can_be_local_p and >>>>>> comdat_can_be_unshared_p predicates. Similar problem happens to clones created >>>>>> by ipa-cp. >>>>>> >>>>>> I guess we want to disable localization and cloning in this case as well. >>>>>> I wonder what else. >>>>> >>>>> Yes, I think we should make -finline-only-static incompatible with cloning and tree-sra too. >>>>> >>>>> Qing >>>>>> >>>>>> Honza >>>
