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 [PATCH] csky: Implement _THIS_IP_ using inline asm 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 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.