Messages in this thread | | | From | Huacai Chen <> | Date | Sat, 30 Jul 2022 18:38:53 +0800 | Subject | Re: [PATCH v4 0/4] LoongArch: Support new relocation types |
| |
On Sat, Jul 30, 2022 at 5:51 PM Xi Ruoyao <xry111@xry111.site> wrote: > > On Sat, 2022-07-30 at 14:44 +0800, Lulu Cheng wrote: > > > > If addr_global is rejected or not implemented (for example, building the > > > > kernel with GCC 12), *I expect* the following hack to work (I've not > > > > tested it because I'm AFK now). Using visibility in kernel seems > > > > strange, but I think it may make some sense because the modules are some > > > > sort of similar to an ELF shared object being dlopen()'ed, and our way > > > > to inject per-CPU symbols is analog to ELF interposition. > > > > > > > Sadly, I don't know what visibility is, does it have something to do > > > with __visible in include/linux/compiler_attributes.h? > > They are different definitions of visibility and mostly unrelated. > Unfortunately humans do not have enough words in the language to > disambiguate those different concepts :). > > -fvisibility and __attribute__((visibility)) are for ELF shared objects. > Kernel developers usually do not need to take care of them (unless > working on VDSO). > > -fvisibility=default (yes, it's the default) makes the symbol "possible > to be interposed" while -fPIC. Say > > $ cat main.c > extern int f(void); > extern int printf(const char *, ...); > int x = 1; > int main() { printf("%d\n", f()); } > $ cat shared.c > int x = 42; > int f(void) { return x; } > $ cc shared.c -fPIC -shared -o libshared.so > $ cc main.c -L. -Wl,-rpath,. -lshared > $ ./a.out > 1 > > You may think it strange but it's so-called "symbol interposition" > mandated by ELF spec. To make it work, the compiler has to use GOT > access for "x" instead of PC-relative access. > > OTOH, a "hidden" visibility disallows interposition: > > $ cat shared-1.c > __attribute__((visbility("hidden"))) int x = 42; > int f(void) { return x; } > $ cc shared-1.c -fPIC -shared -o libshared.so > $ ./a.out > 42 > > Now the compiler will use PC-relative access for "x" in "f". > > In my hack the combination of "-fPIC" and > "__attribute__((visibility("default")))" for per-CPU symbols makes per- > CPU symbols accessed via GOT, and "-fvisibility=hidden" keeps normal > symbols accessed via PC-relative within a TU. > > Note that the visibility of a symbol is also recorded in the symtab, and > ld.so will refuse to access a hidden symbol in one shared object from > another. But the kernel module loader just doesn't care the visibility > field in symtab so it won't affect us. > > Basically the hack just uses visibility options & attributes *in a way > they are not designed for* to trick the compiler to emit GOT accesses > for per-CPU symbols. A new attribute ("get_through_got"/"movable" or > whatever) is definitely wanted to avoid such a tricky approach, but the > hack can be used if we want modular kernel able to be built with GCC 12. So it has nothing to do with __visible in include/linux/compiler_attributes.h? Or __visible is a similar thing that used by Linux kernel?
Huacai > -- > Xi Ruoyao <xry111@xry111.site> > School of Aerospace Science and Technology, Xidian University
| |