From: Xi Ruoyao <xry111@xry111.site>
To: Lulu Cheng <chenglulu@loongson.cn>
Cc: gcc-patches@gcc.gnu.org, liuzhensong <liuzhensong@loongson.cn>,
Chenghua Xu <xuchenghua@loongson.cn>,
Huacai Chen <chenhuacai@kernel.org>, Wang Xuerui <i@xen0n.name>,
Fangrui Song <maskray@google.com>
Subject: Re: [PATCH] LoongArch: add -mdirect-extern-access option
Date: Sun, 04 Sep 2022 21:29:38 +0800 [thread overview]
Message-ID: <85f5b71117deb7a8d83931d79466357d29b749cf.camel@xry111.site> (raw)
In-Reply-To: <CAFP8O3+TquG2+WYpJ-tM2UBpDnU457zaXW1+Ha4Fy1+wRh8S+w@mail.gmail.com>
On Sun, 2022-09-04 at 00:38 -0700, Fangrui Song wrote:
> On Sun, Sep 4, 2022 at 12:00 AM Lulu Cheng <chenglulu@loongson.cn>
> wrote:
> > I have thought about this problem. For example, there is no '%plt'
> > in
> > aarch64, but I think it can be added and easily distinguished at the
> > assembly code level,
> >
> > so this is not removed.
>
> I think @plt should be removed unconditionally. It was a mistake in
> some ABI (e.g. i386, riscv).
I've sent v2
(https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600955.html),
with TARGET_DIRECT_EXTERN_ACCESS check in loongarch_symbol_binds_local_p
so we don't need to duplicate the check 3 times.
Regarding "%plt", I still suggest to remove it globally. It's not so
easy to be distinguished in the compile time, as only the linker will
know if the PLT should be used (unless, if -fPIC -fplt and calling a
default-visible function then we know PLT must be used). An explicit
"%plt" sometimes misleads newbies to think %plt would force the linker
to emit a PLT entry but it's not true. You can discuss this with
Zhensong internally in the following week, I think.
But let's defer the "controversial" thing and eliminate the GOT in
upcoming Linux-6.1 first...
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
prev parent reply other threads:[~2022-09-04 13:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-01 10:54 Xi Ruoyao
2022-09-02 3:12 ` Huacai Chen
2022-09-02 3:31 ` Xi Ruoyao
2022-09-02 11:30 ` Xi Ruoyao
2022-09-04 0:52 ` Fangrui Song
2022-09-04 2:26 ` Lulu Cheng
2022-09-04 2:51 ` Xi Ruoyao
2022-09-04 3:22 ` Lulu Cheng
2022-09-04 6:35 ` Xi Ruoyao
2022-09-04 7:00 ` Lulu Cheng
2022-09-04 7:38 ` Fangrui Song
2022-09-04 13:29 ` Xi Ruoyao [this message]
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=85f5b71117deb7a8d83931d79466357d29b749cf.camel@xry111.site \
--to=xry111@xry111.site \
--cc=chenglulu@loongson.cn \
--cc=chenhuacai@kernel.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=i@xen0n.name \
--cc=liuzhensong@loongson.cn \
--cc=maskray@google.com \
--cc=xuchenghua@loongson.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).