From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 42855243B9 for ; Mon, 4 Nov 2024 09:10:49 +0100 (CET) Received: (qmail 3672 invoked by uid 550); 4 Nov 2024 08:10:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com x-ms-reactions: disallow Received: (qmail 3631 invoked from network); 4 Nov 2024 08:10:45 -0000 X-Sender-Id: dreamhost|x-authsender|rob@landley.net ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1730707833; a=rsa-sha256; cv=none; b=UA1ZPElX4qVw2aW7WGdt59TKUaOA14OeRMGQ3xmGA5+WkboR/fyns/G1ilitYQcBFfowgk u1coQ/KiMjS2emG4RWe8NVfORS1XprcGczm0Cqlt/Leh+1IW1DdRfKjqVVdlEKZsf384Zu XomYf/q+8qahivtjcmtGcw5cZ0LH0T+hwgmPkjqLM7C+LLKnkLwexT0Wuyc6vtmoFg6e3E F53rnc9KvUBTeSGxPl4nBUf6IWbsu5mrvwfLfMIyiqiJ6qOEqsOV9pIYpWWyQbgnPdVBBn i4aMQo0KTeEvl6WoCbTN93Y/EJtCX1gL2i8Nxmmn/rfZ0iAYSPIXsIp4S6gnmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1730707833; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7fmeiG6ByYxhpJTcHlq2hrQoZrQN3wJw7vedwTLKlGU=; b=kACAO9ulFYUkyDf4XGOcIv4hCJSqQ+2ONa7+NLFMzcMfzH/qqjvZ9761IaVNmXs8CS6Yny LzEt0v7U39p88nH/qSkvzYMOpQO7k/IMOBMA6mGiYbe7lYkDrtkln6GDp2LkT7PFQ21ozd 8/3wLzWVCTaeKT2dnYlBI1Ksg1Y0cu8zyUepB9kGEaR+6wnxfmn0SVnTs0ooU8NZTrfDrz j4IC2Qu6Q2CFsm69XELv4Ijr5LPKFlXvrshvX1F6Bo1dddelfbph987oQl6QvyrPJLTEap Z3Mq7Z73AFo1/ZSI+MYlc35rFBDWZOE3w+8RDaQeGyqrnbbZj/1I1fMYsFT8jg== ARC-Authentication-Results: i=1; rspamd-57ff586b7f-ht9g9; auth=pass smtp.auth=dreamhost smtp.mailfrom=rob@landley.net X-Sender-Id: dreamhost|x-authsender|rob@landley.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|rob@landley.net X-MailChannels-Auth-Id: dreamhost X-Harmony-Zesty: 00037ae372e95a63_1730707834074_3216935730 X-MC-Loop-Signature: 1730707834074:1751846434 X-MC-Ingress-Time: 1730707834074 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley.net; s=dreamhost; t=1730707833; bh=7fmeiG6ByYxhpJTcHlq2hrQoZrQN3wJw7vedwTLKlGU=; h=Date:Subject:To:From:Content-Type:Content-Transfer-Encoding; b=K/36HMSFdpjkeZY7kglG4ZQIQ/bW8JblwB9JE1p4uXrqTlYSLHGZv3Pyrnm8T2X68 l4wWYRWH1MAdcjrXsGS/SBPQps/upgko8+p8WtvI+PIF8GzFPFfflV1JH6CoLg4VzE Ta1VjtWtOGgxjXuOBDriC/2Z6z1Eq0tsfQFdA5Yva67idsz3y3e8JRdStvJQdsPypH fESfPGYosEMHyUa0fLNNHGvuTU+WEm5flU47qza+eDma4bkHsbVZXeWDijGZKnUHhr 57V/A5dTmR53kjsnYHSNVyaTgZjekAPFYeobUYucEr04r2WU4s31E7N+CkTuaN35lS 5gGu/xofnh6zg== Message-ID: <49c8fa8d-edf5-4f21-8676-1fb8b34af710@landley.net> Date: Mon, 4 Nov 2024 02:10:32 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: musl@lists.openwall.com, Rich Felker , =?UTF-8?B?44GL44GM44KE44GP44Gy44GL44KK?= <1486864380@qq.com> References: <20241104010123.GD10433@brightrain.aerifal.cx> Content-Language: en-US From: Rob Landley In-Reply-To: <20241104010123.GD10433@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] Does musl support FDPIC on targets other than SH? On 11/3/24 19:01, Rich Felker wrote: > On Sun, Nov 03, 2024 at 03:52:31PM +0800, かがやくひかり wrote: >> Does musl support FDPIC on targets other than SH, for example on ARM? > > At present, no, but the FDPIC implementation in musl is pretty much > entirely arch-agnostic. Upstream GCC ARM-FDPIC introduced some bugs > that need to be fixed, but that's not too hard, and if I remember > right there's a work-in-progress ARM-FDPIC port for musl that could be > polished up and merged if someone has the interest to help test and > address any open questions/problems. I'm interested in following this work if you have pointers. I tried to get arm fdpic to do something useful a few months back and couldn't, and unfortunately sh and arm are the only two targets that gcc and the linux kernel currently both (claim to) support fdpic for: https://lists.gnu.org/archive/html/qemu-devel/2024-10/msg05476.html Alas, every other nommu target in buildroot or https://github.com/gregungerer/simple-linux uses PIE binaries, which scale terribly on nommu. On the gcc side searching for "fdpic" in gcc/config/* hits arm, sh, frv, and blackfin, but support for those last two architectures was removed from Linux due to lack of maintainers in 2018. On the linux side linux/fs/Kconfig.binfmt has: config BINFMT_ELF_FDPIC bool "Kernel support for FDPIC ELF binaries" default y if !BINFMT_ELF depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) Which SEEMS to give 3 more options, but I can't find a compiler for any of them. I can build the fdpic loader for m68k (if I disable nommu support), but it's just a way of loading PIE binaries on nommu, there's no fdpic compiler for m68k: https://www.spinics.net/lists/linux-m68k/msg24781.html I could try to give xtensa a go, I've been vaguely following their out-of-tree musl support since they got it working in 2016 and https://www.openwall.com/lists/musl/2024/05/06/7 presumably applies to current, but again I dunno where to get a compiler, and whether they actually have proper fdpic support rather than just PIE. (Where are the extra registers to hold the separate segment bases defined in the loader arch code?) Last I heard the riscy people were removing nommu support from that architecture entirely, ala https://lore.kernel.org/linux-riscv/20240226140649.293254-1-cleger@rivosinc.com/ but I don't know if they actually went through with it. I haven't been following it closely because I can't bring myself to care about open source doing its own itanium, but a lot of other people do... (It's possible some architectures are still using binflt, which I still think of as a.out for nommu, but I haven't made the bolt-on elf2flt converter work in years...) Rob P.S. My patch to use the fdpic loader on arch/sh with MMU enabled like ARM can is https://landley.net/bin/mkroot/latest/linux-patches/0002-sh4-fdpic.patch which allows testing an fdpic userspace under qemu-system-sh4. Rich said you don't need it, but never explained how. The regular ELF loader could not run fdpic binaries when I tried it, and it wouldn't exercise the fdpic loader codepath anyway (separately distributing the segments). I'm all for someday merging fs/binfmt_elf.c and fs/binfmt_elf_fdpic.c like ext2/3/4 got merged into one driver, but that's not the kernel that's shipping today...