mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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);
> 


  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®