From: Helge Deller <deller@gmx.de>
To: "Thomas Weißschuh" <linux@weissschuh.net>,
"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
"Willy Tarreau" <w@1wt.eu>
Cc: linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org
Subject: Re: [PATCH 2/3] selftests/nolibc: avoid function pointer comparisons
Date: Tue, 7 Apr 2026 19:20:12 +0200 [thread overview]
Message-ID: <d43a2894-9f78-4fc2-b228-2c29ef6daa58@gmx.de> (raw)
In-Reply-To: <20260407-nolibc-hppa-v1-2-f70b4509c44a@weissschuh.net>
On 4/7/26 18:37, Thomas Weißschuh wrote:
> The upcoming parisc support would require libgcc to implement function
> pointer comparisons. As we try to avoid the libgcc dependency rework
> the logic to work without such comparisons.
Instead of working around at this specific code, I think it makes more sense
to simply add the __canonicalize_funcptr_for_compare() symbol somewhere.
Code is in arch/parisc/kernel/real2.S:
ENTRY_CFI(__canonicalize_funcptr_for_compare)
#ifdef CONFIG_64BIT
bve (%r2)
#else
bv %r0(%r2)
#endif
copy %r26,%r28
ENDPROC_CFI(__canonicalize_funcptr_for_compare)
Or am I missing something?
Btw, since you want to avoid libgcc, I think this is quite hard, since
gcc automatically adds lots of parisc specific millicode functions (see the "$$" symbols
in parisc_ksyms.c) and many of the gcc helper functions (e.g. __muldi3).
So, I'm not sure if it makes sense to try to avoid libgcc....
Helge
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> tools/testing/selftests/nolibc/nolibc-test.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
> index d3c4facb54c0..de4e87586d75 100644
> --- a/tools/testing/selftests/nolibc/nolibc-test.c
> +++ b/tools/testing/selftests/nolibc/nolibc-test.c
> @@ -647,20 +647,25 @@ int expect_str_buf_eq(size_t expr, const char *buf, size_t val, int llen, const
> return 0;
> }
>
> +enum strtox_func {
> + strtox_func_strtol,
> + strtox_func_strtoul,
> +};
> +
> #define EXPECT_STRTOX(cond, func, input, base, expected, chars, expected_errno) \
> - do { if (!(cond)) result(llen, SKIPPED); else ret += expect_strtox(llen, func, input, base, expected, chars, expected_errno); } while (0)
> + do { if (!(cond)) result(llen, SKIPPED); else ret += expect_strtox(llen, strtox_func_ ## func, input, base, expected, chars, expected_errno); } while (0)
>
> static __attribute__((unused))
> -int expect_strtox(int llen, void *func, const char *input, int base, intmax_t expected, int expected_chars, int expected_errno)
> +int expect_strtox(int llen, enum strtox_func func, const char *input, int base, intmax_t expected, int expected_chars, int expected_errno)
> {
> char *endptr;
> int actual_errno, actual_chars;
> intmax_t r;
>
> errno = 0;
> - if (func == strtol) {
> + if (func == strtox_func_strtol) {
> r = strtol(input, &endptr, base);
> - } else if (func == strtoul) {
> + } else if (func == strtox_func_strtoul) {
> r = strtoul(input, &endptr, base);
> } else {
> result(llen, FAIL);
>
next prev parent reply other threads:[~2026-04-07 17:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 16:37 [PATCH 0/3] tools/nolibc: add support for 32-bit parisc Thomas Weißschuh
2026-04-07 16:37 ` [PATCH 1/3] parisc: Makefile: use the regular compiler to build a native 32-bit vDSO Thomas Weißschuh
2026-04-07 17:14 ` Helge Deller
2026-04-07 18:06 ` Thomas Weißschuh
2026-04-07 19:27 ` Helge Deller
2026-04-07 20:20 ` Helge Deller
2026-04-07 21:27 ` Thomas Weißschuh
2026-04-07 22:33 ` Helge Deller
2026-04-07 16:37 ` [PATCH 2/3] selftests/nolibc: avoid function pointer comparisons Thomas Weißschuh
2026-04-07 17:20 ` Helge Deller [this message]
2026-04-07 18:11 ` Thomas Weißschuh
2026-04-07 16:37 ` [PATCH 3/3] tools/nolibc: add support for 32-bit parisc Thomas Weißschuh
2026-04-07 17:33 ` Helge Deller
2026-04-07 18:14 ` Thomas Weißschuh
2026-04-07 18:40 ` Helge Deller
2026-04-07 18:50 ` Thomas Weißschuh
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=d43a2894-9f78-4fc2-b228-2c29ef6daa58@gmx.de \
--to=deller@gmx.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=w@1wt.eu \
/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®