> > Is it because you generate something manually and want to limit that > > work, > > I think that this is one of the reasons. > and as mentioned in my writeup, the targeted users of this new functionality is for live-patching users who generate > patches by hand. Ok just means they need better tooling. > in which, it explains that these new options are for helping live-patching users who create patches entirely by hand, including kernel > live-patching scheme kGraft, and one of our internal customers. It sounds to me the problem is not gcc here, but an inefficient scheme to create patches. > the major reason is to control the code size explosion of manual patches. It’s the request from our internal customer. So essentially you want to disable inlining. The Linux kernel code heavily relies on inlining to optimize constants and remove unnecessary code paths. For example I cannot even imagine how horrible the code for get/put/copy_*_user would be if you just disabled inlining on it. That's a fairly common coding pattern in core kernel code and it's not going away. I think the time that is spent here pessimizing code would be far better spent creating better tools to create patches. There's a reason why near all people stopped writing things manually in assembler and moved to compilers. Same reasons should apply to patches. > I think that the current option > -fease-live-patching=inline-clone -flive-patching-list > > should automatically ONLY enabling inline+clone optimization (disable all other ipa optimization/analyses at the same time) and generate the impacted function > list for each of the function. Dwarf2+ has all the information that is needed to find inlines and clones already. e.g. systemtap and gdb and perf probes and most other debuggers support it fine to find all copies of a given line. I wrote parsing tools for that too and it's not too difficult to use. -Andi
