From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (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 06B8C219FC for ; Sun, 1 Feb 2026 18:14:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769969667; cv=none; b=hyQFcAkHqRzi5O1v0HTcUPi3Pmvn53Q8/YEDYO0l2NBkPg8L2Lvioi3VLJ4dcCpTVgV30+izu7GcA/089U9VrWplzAO66go64oFWxpXtProJyuPD/xUR1pPkaEFAqeCc9bpPT7mWMl+Y9bf4Ha4TzV8/BuUX/s79V7cS8iTxnYg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769969667; c=relaxed/simple; bh=pRzybVtL9DL5GA5omV4Ah4PtYBvn/2vOJnW3VXJFxOM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ko8Ej8G44kkLpegQYNx2ct2qJhprEWL8HGj4qrf2DBaewcfx1Uyrd2uz7uAuvmm041PdQbhs/64wZ1CaUi6buI2eQgvtixN3naFvjhAzhJjLHfTKj4ar8Uoh05qc0+ydKzq+IAPEn6Nr/L/a81wVfyd0gkxq8VzXHUFFoZMazQs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=FO20OBR/; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="FO20OBR/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1769969663; bh=EaItlwJZxK+iRjq+hJXhpmOBlDU+kkMSFPz8BzjDUJc=; h=From:Message-ID:From; b=FO20OBR/XdkI4sB+fau29DkvsXs1DMvnvEU4cLFZfkFZ86PAuD5KpsvBYZuIV4JJd RuTd8YTGgHMgAw8gLrYNAxJ3zbR+H5I30WVSPB5JMzcnUseIFFIAlH+sF+MSOVsWwd IARr6WIBh1zc7duI5mWEdHQg5nNKTpa7jbR3+dqI= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 16F60C0AAD; Sun, 01 Feb 2026 19:14:23 +0100 (CET) Date: Sun, 1 Feb 2026 19:14:22 +0100 From: Willy Tarreau To: Daniel Palmer Cc: linux@weissschuh.net, kees@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/9] nolibc: Add static-pie support Message-ID: References: <20260131074440.732588-1-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: <20260131074440.732588-1-daniel@thingy.jp> On Sat, Jan 31, 2026 at 04:44:31PM +0900, Daniel Palmer wrote: > For more background see: > https://lore.kernel.org/lkml/20260116122812.2421621-1-daniel@thingy.jp/ > > Basically I am trying to run normal ELF binaries created with > nolibc on nommu (m68k, 68000). To make this work without an external > linker nolibc needs code to do the relocation. > > The following is my attempt at doing this by hacking just enough > together that static-pie binaries work on a few archs. > The ones that work have a patch in this series. > > Answers to questions you might have: > Q: Don't we need to handle more relocation types? > A: Maybe, everything exception sparc only had R_x_RELATIVE in > the nolibc test binary. sparc emits R_SPARC_NONE as well. > > Q: Don't we need to make some sections writable for this to > work. > A: Maybe, I tried to get most of the supported archs working. > The only one that had relocations on a non-writable section > was arm64 and I think I can fix it so it doesn't need that. > > Q: Why can't you just pass -static-pie to gcc? > A: Only x86 seemed to actually produce static PIE binaries doing > that. Everything else produced normal static ones. Maybe this > is a compiler version thing? > > There are probably things I'm missing, things I have done totally > wrong. Please feel free to grill me. I'm noticing a significant size increase with this change, and I'm not sure all of it is well justified: $ size nolibc-test-* text data bss dec hex filename 43300 120 112 43532 aa0c nolibc-test-6.19-rc7 44524 120 112 44756 aed4 nolibc-test-daniel => +1.2 kB Even a trivial "return 0;" program: $ size ret0-* text data bss dec hex filename 309 24 24 357 165 ret0-6.19-rc7 642 24 24 690 2b2 ret0-daniel => +333 B The difference I'm seeing is here: $ diff -u ret0*size --- ret0-6.19-rc7.size 2026-02-01 19:04:33.918536545 +0100 +++ ret0-daniel.size 2026-02-01 19:04:40.914761767 +0100 @@ -16,4 +16,5 @@ 0000000000000011 W raise 0000000000000012 W abort 0000000000000023 W memmove -0000000000000098 W _start_c +0000000000000086 W __start_c +000000000000015f W _start_c The delta is indeed 333 bytes. Is there anything we could detect at build time to detect that we want to go the heavy way ? Maybe we should only condition that code to __PIE__ ? There's nothing critical, it's really about having an open discussion on this, because we're trying to keep the minimal binaries small, and here we're just doubling the size of the smallest ones all the time. Thanks! Willy