From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from todd.t-8ch.de (todd.t-8ch.de [159.69.126.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AFC7C2DFF04 for ; Mon, 16 Feb 2026 20:51:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.69.126.157 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771275082; cv=none; b=ROq4+Vx1L5NTfrnIdnfRKRliTvEHk0OAqF6jFwRzBlEQTCLM0oCJNYpgN9+IXpl9K6uerid2OGg/YuugopRnioHeOmNq9Yw4EtFhl/XeRvjEuBg7E9wMe6r1J+FnVJ+Fo4TbBwQsQiayTRJIr16m+szRHc+Gh4d0kg6xAMAjQzk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771275082; c=relaxed/simple; bh=Uv+eu6w70XHXTr8CNlPshcsjXgNqMDm+CdmvyxdIgao=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Mf/qveRBq5D4Jf/D/QOXIDtb0UUDXfqj4eml7eKZUVC7/Yq/j82/J9DivvK++DO7YzMH7CFIk3DY/Js+KI5RRiVCRcFcHsJZAZNTxIO7VpSJ0FQtHy+iMteH6q3Gul9BK2kM4ueHdgdlgft1SS8RbwbHhJhyW5jhcPuXzYFgwjQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=weissschuh.net; spf=pass smtp.mailfrom=weissschuh.net; dkim=pass (1024-bit key) header.d=weissschuh.net header.i=@weissschuh.net header.b=FOFXCYA4; arc=none smtp.client-ip=159.69.126.157 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=weissschuh.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=weissschuh.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=weissschuh.net header.i=@weissschuh.net header.b="FOFXCYA4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=weissschuh.net; s=mail; t=1771275079; bh=Uv+eu6w70XHXTr8CNlPshcsjXgNqMDm+CdmvyxdIgao=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FOFXCYA4eCWda+AubzUGHRbU9vAM2MIjTt6o4XAZHEmorqresjdCP0pZYyzLIb1rX Ggqjj7RFDahxXaL1Kt2JnRrFceqIsYySAa2sM6qWmQvhfvzybEmtC1OI4ACg30DOCT NeKRXfb7w4KYt4tqOp7/iZghrjzY3aejm6tUIG1o= Date: Mon, 16 Feb 2026 21:51:19 +0100 From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: Daniel Palmer Cc: w@1wt.eu, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 04/10] tools/nolibc: m68k: Add relocation support Message-ID: <313ca312-b3ff-4f3e-8fe1-22e85fa29e04@t-8ch.de> References: <20260204124542.523567-1-daniel@thingy.jp> <20260204124542.523567-5-daniel@thingy.jp> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260204124542.523567-5-daniel@thingy.jp> On 2026-02-04 21:45:36+0900, Daniel Palmer wrote: > Add support for handling relocations on m68k. > > This also changes the branch to _start_c to be relative. > This might break FLAT binaries so needs to be checked > and probably wrapped in some #ifdef .. magic. You are the expert here, so some more definitive answer to this question would be nice :-) > Signed-off-by: Daniel Palmer > --- > tools/include/nolibc/arch-m68k.h | 27 ++++++++++++++++++++++++++- > 1 file changed, 26 insertions(+), 1 deletion(-) > > diff --git a/tools/include/nolibc/arch-m68k.h b/tools/include/nolibc/arch-m68k.h > index 2a4fbada5e79..e82ff48d3fb8 100644 > --- a/tools/include/nolibc/arch-m68k.h > +++ b/tools/include/nolibc/arch-m68k.h > @@ -10,8 +10,16 @@ > #ifndef _NOLIBC_ARCH_M68K_H > #define _NOLIBC_ARCH_M68K_H > > +#include "elf.h" > + > +#ifdef R_68K_RELATIVE > +#define _NOLIBC_ARCH_HAS_RELOC > +#define _NOLIBC_ARCH_ELF32 > +#endif > + > #include "compiler.h" > #include "crt.h" > +#include "reloc.h" > > #define _NOLIBC_SYSCALL_CLOBBERLIST "memory" > > @@ -129,12 +137,29 @@ > }) > > #ifndef NOLIBC_NO_RUNTIME > + > +#ifdef NOLIBC_WANT_RELOC > +static __inline__ int __relocate_rela(unsigned long base, _nolibc_elf_rela *entry) > +{ > + switch (_nolibc_elf_r_type(entry->r_info)) { > + case R_68K_RELATIVE: It seems there is only ever a single relocation used per architecture. So wouldn't it be possible to do something like this: #define _NOLIBC_ARCH_HAS_RELOC #define _NOLIBC_ARCH_RELA_RELOC R_68K_RELATIVE This keeps the per-architecture code simpler and removes the ugly 'ifdef R_68K_RELATIVE'. The code will break if somebody actually tries to build a static pie using old uapi headers, but then this has never worked before anyways. > + __relocate_rela_relative(base, entry); > + break; > + default: > + return -1; > + } > + > + return 0; > +} > +#endif /* NOLIBC_WANT_RELOC */ > + > void _start(void); > void __attribute__((weak, noreturn)) __nolibc_entrypoint __no_stack_protector _start(void) > { > __asm__ volatile ( > "movel %sp, %sp@-\n" > - "jsr _start_c\n" > + "lea _start_c(%pc), %a0\n" > + "jsr (%a0)\n" > ); > __nolibc_entrypoint_epilogue(); > } > -- > 2.51.0 >