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 DA5F217C211 for ; Sat, 7 Feb 2026 15:49:36 +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=1770479377; cv=none; b=nWsIpBVT9f9qiURFCFnH1IX3rmrpOwjfhErfm8CQYR/JfzB7dSO7nj7IJYA6K6ju+U87VGU4GVLFx4z2nSH+3OVEwpf/z6AERqOa5N7QMzxB31iMB8OmiLsHYCLqHr0OWcpmvRfyjmtBv1kJLFcU8RapOMlx1l+x8T0XRCE6C4g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770479377; c=relaxed/simple; bh=V1ioVtxusrWDdQ8G99zIECsTHh9pbZx1ebpFkr4r2k0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ey1CpJvVKLL2IqjFiSxbq8E/tRfMk7ByU/A0qM4mvVPeC5TNqcc9X/J+HxXFgqSlt6oF0g2omF8FWm130V0QGW/NUoePdf5z9LJwJ6ApSAOLmYJmjgP6Fz/J4uGtE1gfHHqwoI2FFSvPDUTqsqDkRMGAjmEIuHO043w4nc1E75g= 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=HoNOpWE3; 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="HoNOpWE3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1770479375; bh=SJqOV/DWfY4I6EXx6aOxmpahkad8qth2IYR4+MEK48A=; h=From:Message-ID:From; b=HoNOpWE3mTgOPvxzGvnfQWV+fUKnrxlN6XECD9DPJKBjvcs9mX61W35X3FTV/KbzC gsKvJBu/iTaSD7R7ygRGKqa2izyWfnV3b26Law98BIvemjmddW85pI6hbil8Idqhll pc+md9tG3lc2jPcHG0EsWPNrtRYV58GmRnxTXHLI= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 25646C0B44; Sat, 07 Feb 2026 16:49:35 +0100 (CET) Date: Sat, 7 Feb 2026 16:49:34 +0100 From: Willy Tarreau To: Daniel Palmer Cc: linux@weissschuh.net, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 03/10] tools/nolibc: Add basic ELF self-relocation support for static PIE Message-ID: References: <20260204124542.523567-1-daniel@thingy.jp> <20260204124542.523567-4-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-4-daniel@thingy.jp> On Wed, Feb 04, 2026 at 09:45:35PM +0900, Daniel Palmer wrote: > Currently nolibc programs cannot be compiled with -static-pie. > Which is basically no shared libraries, no interpreter, but contain > relocation information in the ELF to allow the program to be fixed > up to run at the address that the kernel loaded it to. > > There might be other use cases for static PIE but mine is for nommu. > The ELF FDPIC loader can actually load normal ELFs is long as they > can be relocated. > > This very basic implementation does the following: > > - Works out if we are PIE and need to be relocated. ELF type == ET_DYN > - Works out if we are static PIE, have no interpreter, and need to > relocate ourselves. > - Calculates the base address using the ELF program header address > given to us by the kernel and the size of the ELF header that > should be directly above. > - Finds the ELF relocation data. > - Calls an arch specific function to handle each of the relocations. > > Note that from testing a lot of archs don't produce static PIE > binaries with the -static-pie option and you need to compile with > -pie -Wl,--no-dynamic-linker to get a static PIE binary. > > Currently REL and RELA formats are supported. So we're clearly past my knowledge of these things and will have to trust you :-) One thing however, please keep in mind that all your _relocate and __relocate* functions will be visible from userland code and as such should be prefixed with "_nolibc" (or even __nolibc) to prevent name conflicts. It's a particular effort we have to do that is caused by the lib's design consisting only in include files: nothing at all is private. Willy