From: David Laight <david.laight.linux@gmail.com>
To: Guo Ren <guoren@kernel.org>
Cc: Marco Elver <elver@google.com>,
linux-csky@vger.kernel.org, linux-kernel@vger.kernel.org,
Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH] csky: Implement _THIS_IP_ using inline asm
Date: Sun, 27 Sep 2026 07:42:10 +0100 [thread overview]
Message-ID: <20260927074210.7495123a@pumpkin> (raw)
In-Reply-To: <CAJF2gTRr2pouJoj=NtofkCW1OgU08Jqoh2B8Guu=FheJMzEGyg@mail.gmail.com>
On Sun, 27 Sep 2026 10:15:11 +0800
Guo Ren <guoren@kernel.org> wrote:
> On Fri, Sep 25, 2026 at 7:51 PM Marco Elver <elver@google.com> wrote:
> >
> > Both GCC [1] and Clang [2] consider the generic version of _THIS_IP_ to
> > be broken:
> >
> > #define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
> >
> > In particular, the address of a label is only expected to be used with a
> > computed goto.
> >
> > While the generic version more or less works today, it is known to be
> > brittle and may break with current and future optimizations. For
> > example, Clang -O2 always returns 1 when this function is inlined:
> >
> > static inline unsigned long get_ip(void)
> > { return ({ __label__ __here; __here: (unsigned long)&&__here; }); }
> >
> > Fix it by overriding _THIS_IP_ in <asm/linkage.h> (which is included by
> > <linux/instruction_pointer.h>) using an architecture-specific inline asm
> > version.
> >
> > This also fixes this GCC ICE [3]:
> >
> > sound/core/oss/mixer_oss.c: In function 'snd_mixer_oss_proc_write':
> > sound/core/oss/mixer_oss.c:1202:1: error: could not split insn
> > 1202 | }
> > | ^
> > (insn 183 400 184 (set (reg:SI 0 a0 [orig:307 _55 ] [307])
> > (xor:SI (reg:SI 3 a3 [orig:308 random_kmalloc_seed ] [308])
> > (const:SI (plus:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
> > (const_int 132 [0x84]))))) "include/linux/slab.h":759:52 288 {cskyv2_xorsi3}
> > (expr_list:REG_DEAD (reg:SI 3 a3 [orig:308 random_kmalloc_seed ] [308])
> > (nil)))
> > during RTL pass: final
> > sound/core/oss/mixer_oss.c:1202:1: internal compiler error: in final_scan_insn_1, at final.cc:2813
> > 0x779b51e2a1c9 __libc_start_call_main
> > ../sysdeps/nptl/libc_start_call_main.h:58
> > 0x779b51e2a28a __libc_start_main_impl
> > ../csu/libc-start.c:360
> >
> > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120071 [1]
> > Link: https://github.com/llvm/llvm-project/issues/138272 [2]
> > Link: https://lore.kernel.org/all/6106aefa-47c7-4bda-a51f-8a2fba3bf715@roeck-us.net/ [3]
> > Tested-by: Guenter Roeck <linux@roeck-us.net>
> > Signed-off-by: Marco Elver <elver@google.com>
> > ---
> > arch/csky/include/asm/linkage.h | 7 +++++++
> > 1 file changed, 7 insertions(+)
> > create mode 100644 arch/csky/include/asm/linkage.h
> >
> > diff --git a/arch/csky/include/asm/linkage.h b/arch/csky/include/asm/linkage.h
> > new file mode 100644
> > index 000000000000..04afd3583e25
> > --- /dev/null
> > +++ b/arch/csky/include/asm/linkage.h
> > @@ -0,0 +1,7 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef __ASM_CSKY_LINKAGE_H
> > +#define __ASM_CSKY_LINKAGE_H
> > +
> > +#define _THIS_IP_ ({ unsigned long __ip; asm volatile("grs %0, ." : "=r" (__ip)); __ip; })
>
> Yes, this is the right fix.
Possibly "grs %0, 0" would be less obtuse.
I think "grs reg, label" is documented as being "grs reg, (label - .) >> 1".
The doc I found has some strange translations in it, grs is "Generate sign".
David
>
> csky has always used the generic label-address _THIS_IP_. That is
> brittle, and on csky the compiler now crashes when that address is
> folded into an immediate. `grs rz, .` materializes the current
> instruction address, so it is the correct replacement.
>
> Acked-by: GUO Ren (XuanTie) <guoren@kernel.org>
>
>
> > +
> > +#endif /* __ASM_CSKY_LINKAGE_H */
> > --
> > 2.56.0.rc1.315.gc6ed9934b7-goog
> >
>
>
prev parent reply other threads:[~2026-09-27 6:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 11:51 Marco Elver
2026-09-27 2:15 ` Guo Ren
2026-09-27 6:42 ` David Laight [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=20260927074210.7495123a@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=elver@google.com \
--cc=guoren@kernel.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/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
all inboxes | Powered by JetHome®