From: Josh Poimboeuf <jpoimboe@xxxxxxxxxx> Date: Fri, 11 Feb 2022 10:35:29 -0800 > On Fri, Feb 11, 2022 at 10:05:02AM -0800, Fāng-ruì Sòng wrote: > > On Fri, Feb 11, 2022 at 9:41 AM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > > > > On Wed, Feb 09, 2022 at 07:57:39PM +0100, Alexander Lobakin wrote: > > > > Position-based search, which means that if there are several symbols > > > > with the same name, the user needs to additionally provide the > > > > "index" of a desired symbol, is fragile. For example, it breaks > > > > when two symbols with the same name are located in different > > > > sections. > > > > > > > > Since a while, LD has a flag `-z unique-symbol` which appends > > > > numeric suffixes to the functions with the same name (in symtab > > > > and strtab). It can be used to effectively prevent from having > > > > any ambiguity when referring to a symbol by its name. > > > > > > In the patch description can you also give the version of binutils (and > > > possibly other linkers) which have the flag? > > > > GNU ld>=2.36 supports -z unique-symbol. ld.lld doesn't support -z unique-symbol. > > > > I subscribe to llvm@xxxxxxxxxxxxxxx and happen to notice this message > > (can't keep up with the changes...) > > I am a bit concerned with this option and replied last time on > > https://lore.kernel.org/r/20220105032456.hs3od326sdl4zjv4@xxxxxxxxxx > > > > My full reasoning is on > > https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#z-unique-symbol > > Ah, right. Also discussed here: > > https://lore.kernel.org/all/20210123225928.z5hkmaw6qjs2gu5g@xxxxxxxxxx/T/#u > https://lore.kernel.org/all/20210125172124.awabevkpvq4poqxf@treble/ > > I'm not qualified to comment on LTO/PGO stability issues, but it doesn't > sound good. And we want to support livepatch for LTO kernels. > > Also I realized that this flag would have a negative effect on > kpatch-build, as it currently does its analysis on .o files. So it > would have to figure out how to properly detect function renames, to > avoid patching the wrong function for example. > > And if LLD doesn't plan to support the flag then it will be a headache > for livepatch (and the kernel in general) to deal with the divergent > configs. I'm always down with replacing any of the parts, I'm just not familiar with any other ways of approaching this without huge diffs. I've read Fāng-ruì's blogpost previously and there's a possible replacement described there, but I dunno how to approach it. And them Miroslav just told me that unique-symbol should work just fine and I can go with it. So I asked here prevously and ask once again for any hints regarding some other ways :p > > One idea I mentioned before, it may be worth exploring changing the "F" > in FGKASLR to "File" instead of "Function". In other words, only > shuffle at an object-file granularity. Then, even with duplicates, the > <file+function> symbol pair doesn't change in the symbol table. And as > a bonus, it should help FGKASLR i-cache performance, significantly. Yeah, I keep that in mind. However, this wouldn't solve the duplicate static function names problem, right? Let's say you have a static function f() in file1 and f() in file2, then the layout each boot can be .text.file1 or .text.file2 f() f() .text.file2 .text.file1 f() f() and position-based search won't work anyway, right? > > -- > Josh Thanks, Al
