From nobody Sun Feb 8 05:28:54 2026 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF32E1C6FF5 for ; Fri, 16 Jan 2026 12:28:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768566507; cv=none; b=uAV5MUj0T973slGagi/gkyU0+jtu9vMFtPdWX6+kj8qPIGIDTRaxDR+bwh95AFTrZhkUXoPkRqtumjsei2UIWOzc88+N/30kl9xObJZXjfC45oXCfJ2TWstTC+Ez2s97M1NdYFTp6ghzUP8CU+2K1BYvPGeE+Q29Y7LtXwXdT/Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768566507; c=relaxed/simple; bh=gYQMQn4Jfdw1G2Wf4o6F1QrEj1e39VDp1Bc+MstZOFI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=u8N/tO0gYmdmiAqTKA8Lpj5gTx5qykBCR8ue+wwRucMBFjjN4X5L1IYQsvB952FjNcmSH1yNmALxHfteyN4fhMUKy+2LI33PTfu5dh3ABFxNxopDRm2V8m96/z3euhFA+qNMHFjL94Y/gjuif4YQjeMJGrCThr3T52t2dB1jAKA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=thingy.jp; spf=pass smtp.mailfrom=0x0f.com; dkim=pass (1024-bit key) header.d=thingy.jp header.i=@thingy.jp header.b=O6tLc3Of; arc=none smtp.client-ip=209.85.214.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=thingy.jp Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=0x0f.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=thingy.jp header.i=@thingy.jp header.b="O6tLc3Of" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2a0c09bb78cso14653225ad.0 for ; Fri, 16 Jan 2026 04:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thingy.jp; s=google; t=1768566503; x=1769171303; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=KAwaQrv1W94Em81hIWbm99vsqb7U2YZNzT5rHF59/C0=; b=O6tLc3OfN5KEUGknt+SlJOy22eoFtnN4sq7wJanq6l9A965lYPtirty6kR1QuzamiU e+a81PhhPhVtmftrYxB7sch0i/fuOKEq0lPKM6BMkceFWgtNxLt6+smYNOoW5woPG0PC YhkQbQrrQj5bHfBHxzLoEIzoHativXoABxFyY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768566503; x=1769171303; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KAwaQrv1W94Em81hIWbm99vsqb7U2YZNzT5rHF59/C0=; b=K8bvaaxv10vBQXD9MwxdvrEjfPovuS6O2YSikJjGKJDduwvEgk6JL/htwtx4FnfNjL VSDj0mQFQ6xIXrKiYR0pcHW7yVfYVs7yUlNxTqhfs98HoOFb+eQVcFVKXOT/A0x19Wwp MI6+uduXncT8Cq2qGIpSYdy/vHOneYVGw3ORUHPrNDlwwtlyPHgZrYeWF50IeDc8KBJ+ wrBGaWSD5pt/Ihxf6cQF5JULgA++rPk48uX89f9oS09b9Q2c7c1gGUNEU0LVN2tW065x Q0JrApijcuiT1xS3uaqWWZvy3v+7c6x4jw7qaPcCx1jzraRgbxZ/jn2OrxsFPD83UOtZ e3qQ== X-Forwarded-Encrypted: i=1; AJvYcCWPRq++RzSPMbKH3OwF851ZkzPA9wl9ROHco/WjpmCqrh3D2hyvafwv1ECcJkTZHhm6z0VnXxHv/U8ngD0=@vger.kernel.org X-Gm-Message-State: AOJu0YxLnrNJdrZcbt+i22zQW290DdGlUsQ8hzQOcl92El9CYAdkHXSH A7CvfRONwLePHLRwA89oaRWqReC1xrnLeoPnndprrVcWY6pTXa26/o+MwroZl/EM6YU= X-Gm-Gg: AY/fxX4X1JMJyuXpOdLSxpfMC4x4MamiKH3V5a9Vv16hjbgrR2SJEhvPgNhCwUd+LAx qp08mmEEO8pR6LGBRi0epSy92TNQvsIYtKdJ0MZguR6Lg9FbtrlNVskvB+quwcq4P1Bi+8LIsnD 5gmU6aOyfJcII7o4vciD4dxurgne/Nu3mpjW4yDXWMqmdP3hvLWxBsnYdlELwxPoqHHhGZil84t 7Q8XY7ULyZzmBDkmJrx8OtnBj3+yCy2d2iLUn2Ry2NEL4aTQKh21wjmA1ZQ1W4mWulzyk0SS7Od BVb99ID6HktKGxO6/sCwyqsnvyW6HvepeqePpOhev3yZc+Q3w9fYGtUQm4Nu8Zps1nL9BQc+H98 lxK6Q6QlCTwZYFB0WE3m3JoIQqCCqV9EYSmnZabtKOgZgCMKcByriZw4BXEJuQ+Wreo8u8svt7c K38kn0R8GJPj3Q/9SiJoF2cBHR280e4BdbMBD1iNFctUv8UbIroGwr7DYNrt8qLLlIScHtGmf07 bg= X-Received: by 2002:a17:903:b0f:b0:2a1:3769:1d02 with SMTP id d9443c01a7336-2a717583bb1mr28248835ad.12.1768566502975; Fri, 16 Jan 2026 04:28:22 -0800 (PST) Received: from kinako.work.home.arpa (p1567014-ipxg00c01sizuokaden.shizuoka.ocn.ne.jp. [153.226.195.14]) by smtp.googlemail.com with ESMTPSA id d9443c01a7336-2a7193dbb37sm20583555ad.46.2026.01.16.04.28.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jan 2026 04:28:22 -0800 (PST) From: Daniel Palmer To: w@1wt.eu, linux@weissschuh.net, gerg@linux-m68k.org, dalias@libc.org Cc: linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org, Daniel Palmer Subject: [RFC PATCH] tools/nolibc: HACK!: Add basic self relocation for static PIE for m68k nommu FDPIC Date: Fri, 16 Jan 2026 21:28:12 +0900 Message-ID: <20260116122812.2421621-1-daniel@thingy.jp> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This is some very quick hacky code to test if this works and get some ideas= .. - I'm messing with m68k nommu. Currently I use FLAT binaries and this is wo= rking with nolibc as-is mostly. Sometimes some relocations that elf2flat doesn't like get g= enerated and the resulting FLAT binary doesn't have any relocation information and crashes= which isn't good if you don't have an mmu. - Since commit 1bde925d2354 ("fs/binfmt_elf_fdpic.c: provide NOMMU loader f= or regular ELF binaries") the FDPIC loader has apparently been able to load non-FDPIC binaries as l= ong as they are PIE and can be relocated. I have been messing with this thinking that may= be I can stop using FLAT binaries. - By default linking with -pie is trying to set ld.so as the interpreter to= do the relocation. I don't think I have anything that can do that in my system. = I am using uclibc but statically linked. Aside from my programs written with nolibc there is a = busybox FLAT that is statically linked to uclibc and nothing else. Eitherway, the plan is not to have any libc and have everything compiled = with nolibc. I'm writing a small init, shell etc with nolibc that will replace busybox and not cau= se constant OOMs. - So, I can generate PIE binaries but they can't work because I have no lin= ker to relocate them but apparently static PIE is a thing and with a normal toolchain you'd get a = crt that does the relocation before jumping to main(). - I thought it shouldn't be too hard to add something like that to crt.h in= nolibc and then pass --no-dynamic-linker when linking to not set an interpreter. - I got it working enough that a static pie "hello, world" loads and runs: / # /root/test.elf [ 9.970000] FDPIC ____ LOAD 23 ____ [ 9.970000] FDPIC Mapped Object [executable]: [ 9.970000] FDPIC - elfhdr : 6d8000 [ 9.970000] FDPIC - entry : 6d83e4 [ 9.970000] FDPIC - PHDR[] : 6d8034 [ 9.970000] FDPIC - DYNAMIC[]: 6da7b0 [ 9.970000] FDPIC - LOAD[0] : 006d8000-006d87ad [va=3D0 ms=3D7ae] [ 9.970000] FDPIC - LOAD[1] : 006da7b0-006da873 [va=3D27b0 ms=3Dc4] [ 9.970000] FDPIC - start_code 6d8000 [ 9.970000] FDPIC - end_code 6d87ae [ 9.970000] FDPIC - start_data 6da7b0 [ 9.970000] FDPIC - end_data 6da874 [ 9.970000] FDPIC - start_brk 6e0000 [ 9.970000] FDPIC - brk 6e0000 [ 9.970000] FDPIC - start_stack 6fff00 hello, world! [ 9.980000] test.elf (23) used greatest stack depth: 5348 bytes left Questions: - My use case is weird/niche but maybe there are uses for static pie nolibc= binaries? - If so what would be a cleaner way of implementing this? - Right now the base address offset all of the relocations against is hardc= oded. Maybe someone knows how I'm meant to get that properly? Signed-off-by: Daniel Palmer --- tools/include/nolibc/crt.h | 56 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/tools/include/nolibc/crt.h b/tools/include/nolibc/crt.h index d9262998dae9..0931915280d8 100644 --- a/tools/include/nolibc/crt.h +++ b/tools/include/nolibc/crt.h @@ -10,6 +10,7 @@ #ifndef NOLIBC_NO_RUNTIME =20 #include "compiler.h" +#include "elf.h" =20 char **environ __attribute__((weak)); const unsigned long *_auxv __attribute__((weak)); @@ -47,6 +48,61 @@ void _start_c(long *sp) /* initialize stack protector */ __stack_chk_init(); =20 +#ifdef NOLIBC_STATIC_PIE +#define R_68K_RELATIVE 22 +{ + void *base =3D (void *) 0x6d8000; // TODO: how to actually get this? + unsigned int rela_count =3D 0; + unsigned int rela_off =3D 0; + unsigned long dyn_addr; + Elf32_Rela *rela; + Elf32_Addr *addr; + Elf32_Dyn *dyn; + int i; + + /* For m68k with the FDPIC loader d5 contains the offset to the DYNAMIC s= egment */ + __asm__ volatile ( + "move.l %%d5, %0\n" + : "=3Dr" (dyn_addr) + ); + dyn =3D (Elf32_Dyn *) dyn_addr; + + /* Go through the DYNAMIC segment and get the offset to rela and the numb= er of relocations */ + for (; dyn->d_tag !=3D DT_NULL; dyn++) { + switch (dyn->d_tag) { + case DT_RELA: + rela_off =3D dyn->d_un.d_ptr; + break; + case DT_RELACOUNT: + rela_count =3D dyn->d_un.d_val; + break; + } + } + + if (!rela_off || !rela_count) + exit(42); //TODO nonsense error + + rela =3D base + rela_off; + + /* Do the relocations, only R_68K_RELATIVE for now */ + for (i =3D 0; i < rela_count; i++) { + Elf32_Rela *entry =3D &rela[i]; + + switch (ELF32_R_TYPE(entry->r_info)) { + case R_68K_RELATIVE: + { + addr =3D (Elf32_Addr *)(base + entry->r_offset); + *addr =3D (Elf32_Addr) (base + entry->r_addend); + } + break; + default: + exit(43); //TODO nonsense error + break; + } + } +} +#endif + /* * sp : argc <-- argument count, required by main() * argv: argv[0] <-- argument vector, required by main() --=20 2.51.0