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=-2.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 B89EA2B6DE for ; Mon, 4 Nov 2024 15:04:55 +0100 (CET) Received: (qmail 26152 invoked by uid 550); 4 Nov 2024 14:04:50 -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 26120 invoked from network); 4 Nov 2024 14:04:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1730729081; x=1731333881; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iSVDS75ll9S2dYeJ5GVV8a8Rp89IHE69a3B8gOxAjrQ=; b=SP09jIqexdrMP1Qxx033Bfv1NRbOVoAJ6AKkS8fO4s1v1F1GTVv/JJnYCNW63bsX35 6hEB6ubRZMgLbUUptn04f4dp3eotjQ1YCNNjXjNdo5a8VafAt1VpK7YV+8hjxmojgBk1 Lkw1Uuz0GH0Z9DEvEdPlIswDTqnFB9hb7QwnZjPennyPKtCO+PAqSzr60NE+WHFA3V5Z 2uy8Ga5/iMjYJHUh9+Dv3KOV2MZg4kyyKcPn6rwZeSBJMbISis/Nsnu64I6PtZ1K9Oqn MhkBWNUbKeVM8Frs7iPXIfqn1neudTT91aTNSjULgKjogY3nL1e54nCmLlcYqGnJebS3 A9Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730729081; x=1731333881; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iSVDS75ll9S2dYeJ5GVV8a8Rp89IHE69a3B8gOxAjrQ=; b=q8J6l8FBDYT0B9sipjWW4StgPXJiqTIFfpvUhIBqUUbIBaJ6kpREX4lrQ3XJi9Ui5S x2ynRxrcxUmaqnsjNxWWV1s+jvdhs79XWUz3zofWAeXVsAlNNJCG0Sjqj4eYijZzugVE W66fALygNASceTSpzFjGGlB94K4y9hQS5gUCBCaNCsrs6l84WX5QJ4oZ3zBl9doMIGYa 3DIc/CCdyhYLxgWfORpDv/CYpFYtMK+jrFjZSLPiR67vwbURLyA2DlvMDyP6uQHzelNt Js6p2JAwVAVHXu+7GOqC+K7NZwrBhwjftnorGxQ7uAasmGbJcCFvggCS30OaDx2bTwGd Mjhw== X-Gm-Message-State: AOJu0YwtgeFN2Enttn27B5T+h0pNDT1qRDUm0vT12eaN0DJgFdB9vS2N I4YI6ENeIoVvKcDTdzFU1tI6uyWNizlP80QHcP5Ja9ErO2jYJAcoAgfjEKbAMASZV9yoUsfU+IS u6M7WH0AKg0ajOqFStkBVZiJec2Q48zmP26Q0qA10rpnEiB/dO5mf X-Google-Smtp-Source: AGHT+IHDrvjIJLgYe/YnhLfRTETGLbJmD2XxJHJ03Ds4GQB4CjoMJgmr61Eu4bqzbL9BzRKZGpuqMLnRMOZ71yCQrh0= X-Received: by 2002:a05:6214:4803:b0:6d3:69e8:b895 with SMTP id 6a1803df08f44-6d369e8bb8amr128232166d6.12.1730729079114; Mon, 04 Nov 2024 06:04:39 -0800 (PST) MIME-Version: 1.0 References: <20241104010123.GD10433@brightrain.aerifal.cx> <49c8fa8d-edf5-4f21-8676-1fb8b34af710@landley.net> In-Reply-To: <49c8fa8d-edf5-4f21-8676-1fb8b34af710@landley.net> From: enh Date: Mon, 4 Nov 2024 09:04:23 -0500 Message-ID: To: musl@lists.openwall.com Cc: Rich Felker , =?UTF-8?B?44GL44GM44KE44GP44Gy44GL44KK?= <1486864380@qq.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Does musl support FDPIC on targets other than SH? On Mon, Nov 4, 2024 at 3:10=E2=80=AFAM Rob Landley wrote: > > On 11/3/24 19:01, Rich Felker wrote: > > On Sun, Nov 03, 2024 at 03:52:31PM +0800, =E3=81=8B=E3=81=8C=E3=82=84= =E3=81=8F=E3=81=B2=E3=81=8B=E3=82=8A 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. riscv fdpic came up on in the psabi sig meetings a couple of times, but it wasn't obvious to me that anyone actually directly cared/needed it versus "arm32 sort-of has this, so someone might want it for rv32 too, maybe?". > 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@rivosi= nc.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...