All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huacai Chen <chenhuacai@kernel.org>
To: Xi Ruoyao <xry111@xry111.site>
Cc: Lulu Cheng <chenglulu@loongson.cn>,
	Youling Tang <tangyouling@loongson.cn>,
	 loongarch@lists.linux.dev, LKML <linux-kernel@vger.kernel.org>,
	 WANG Xuerui <kernel@xen0n.name>,
	Jinyang He <hejinyang@loongson.cn>
Subject: Re: [PATCH v4 0/4] LoongArch: Support new relocation types
Date: Sat, 30 Jul 2022 18:38:53 +0800	[thread overview]
Message-ID: <CAAhV-H6jAxOx1xfa6N8F5L0Oc-sp9KimQN-Sen6YPDjnRVEMuQ@mail.gmail.com> (raw)
In-Reply-To: <5233653cceab9c2baf6510bd712cd53ef63e3aac.camel@xry111.site>

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

  reply	other threads:[~2022-07-30 10:39 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29  8:38 [PATCH v4 0/4] LoongArch: Support new relocation types Xi Ruoyao
2022-07-29  8:39 ` [PATCH v4 1/4] LoongArch: Add section of GOT for kernel module Xi Ruoyao
2022-07-29  8:40 ` [PATCH v4 2/4] LoongArch: Support R_LARCH_SOP_PUSH_GPREL relocation type in " Xi Ruoyao
2022-07-29  8:41 ` [PATCH v4 3/4] LoongArch: Remove -fplt and -Wa,-mla-* from CFLAGS Xi Ruoyao
2022-07-29  8:42 ` [PATCH v4 4/4] LoongArch: Support modules with new relocation types Xi Ruoyao
2022-08-01  9:45   ` Youling Tang
2022-08-09 11:31   ` Youling Tang
2022-07-29  9:47 ` [PATCH v4 0/4] LoongArch: Support " WANG Xuerui
2022-07-29  9:49 ` Youling Tang
2022-07-29 10:18   ` Xi Ruoyao
2022-07-29 10:36     ` Xi Ruoyao
2022-07-29 11:45       ` Xi Ruoyao
2022-07-29 12:19         ` Youling Tang
2022-07-29 17:55           ` Xi Ruoyao
2022-07-30  2:24             ` Xi Ruoyao
2022-07-30  2:52               ` Xi Ruoyao
2022-07-30  6:14                 ` Huacai Chen
     [not found]                   ` <674cb3e9-d820-016b-a210-afd37ed6e25e@loongson.cn>
2022-07-30  9:51                     ` Xi Ruoyao
2022-07-30 10:38                       ` Huacai Chen [this message]
2022-07-31  3:07                         ` Xi Ruoyao
2022-08-01  2:16                 ` Youling Tang
2022-08-01  2:34                   ` Huacai Chen
2022-08-01  4:31                     ` Youling Tang
2022-08-01  9:55                     ` Xi Ruoyao
2022-08-01 10:08                       ` Jinyang He
2022-08-01 10:44                         ` WANG Xuerui
2022-08-01 11:28                         ` Youling Tang
2022-08-01 11:39                           ` Xi Ruoyao
2022-08-01 12:09                             ` Huacai Chen
2022-08-01 12:13                             ` Youling Tang
     [not found]                               ` <98efbf76-fbf3-f90b-82d4-bd2874088d05@loongson.cn>
2022-08-02  7:15                                 ` Xi Ruoyao
2022-08-27 13:20                                   ` Huacai Chen
2022-08-01 10:41                       ` Huacai Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAhV-H6jAxOx1xfa6N8F5L0Oc-sp9KimQN-Sen6YPDjnRVEMuQ@mail.gmail.com \
    --to=chenhuacai@kernel.org \
    --cc=chenglulu@loongson.cn \
    --cc=hejinyang@loongson.cn \
    --cc=kernel@xen0n.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=tangyouling@loongson.cn \
    --cc=xry111@xry111.site \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.