Messages in this thread | | | Subject | Re: [PATCH v4 0/4] LoongArch: Support new relocation types | From | Xi Ruoyao <> | Date | Sat, 30 Jul 2022 17:51:12 +0800 |
| |
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. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University
| |