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.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE 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 762D12140C for ; Fri, 16 Feb 2024 19:24:59 +0100 (CET) Received: (qmail 14292 invoked by uid 550); 16 Feb 2024 18:21:49 -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 Received: (qmail 14251 invoked from network); 16 Feb 2024 18:21:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley-net.20230601.gappssmtp.com; s=20230601; t=1708107885; x=1708712685; darn=lists.openwall.com; h=in-reply-to:references:cc:to:from:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=u3Y4sMCkAEN1dJ3u6Rl2m7bGoJBzE6Wp/k1NISd1rsM=; b=CFtMMkIQzdohb2f55Wra6SKDBVrr6ojADp2PQmJggqbgUNFnIB6CDsswiVTpOZt16a 9kDBwyn40GUhL4FxxD1ABHj5tmAxfgYgoiA3nP84U+Nz/SToFogrebePSJTp3ROS6V6M 37StkGDgNQipvgA0oGWscXoj79QFMGsfs8ushz2Lj6EiXas7qbbCS7hErM2r5+VUSGGZ vLHaymD+8vxVvH3UJiwPAhTM+wi0GC7hjwkKWiYS0b9XbmlMQh8DkcGAhDNPeocrNpkZ whUOah5Q/GxwRcQh6XOmECKTuxoz7Mmk+HET1mGx5fCMtV9qwcj2uK/d6WH4a3yAZKCD iyVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708107885; x=1708712685; h=in-reply-to:references:cc:to:from:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=u3Y4sMCkAEN1dJ3u6Rl2m7bGoJBzE6Wp/k1NISd1rsM=; b=EJ1hGjHt2XyWNztfBQM30VW3DdPSDq1LxmEJzK8k/rkPd0tP4vRL4S4NlHR+29KWea TfHFkqhwMQgH32ukCEMqMya/57jLv8hmf4wNJo5dlGmDRR/WL1sYfec7VEfXNZGpo16H YMwvNoNTXYaLX8ZwpEaVAq9yntwO8ELiXK+XOBZuDKAKv4RHejFEQVKa/JV1/GjF0q7i aOyyWqaCoOVswlEb/oif9THJguR8r+MHqEgdH6UJoqYv0AuiKgeIsrSm2bPMaCYY2DiI 543B7mjif27gZ2G+LZhn2OQIt+snsp1M1jS1/nIDRXQEvuLCt9icZiE2xx0b9e6uDEpJ iZgg== X-Forwarded-Encrypted: i=1; AJvYcCXEPvvX+oX7iauTwrQYL9wQlYpq8GLI7abCYlIVRLGQMTZCyLvyOIyKYQXT45GGnZNiI7JjZRcjjUiiAa1+OVjofpw2ThwewQ== X-Gm-Message-State: AOJu0Yxb13X8f/BtbvlmDKIfiEl71lyjX2hNrpV+l3lxJgGV73yI15no U63agyN+AU4dg8OHJuLxix81sYluEfg/+nuX+dNWz/DwByF5FPkPXSG5vo7nDbo= X-Google-Smtp-Source: AGHT+IHpdTodcv8FhKKnU32oTFi+XCtlV8SoOzpn2BtppB9a53IjR1FmjSjwZyAE0XAXzuGF/Zn4Pg== X-Received: by 2002:a05:6870:158c:b0:21e:389a:214 with SMTP id j12-20020a056870158c00b0021e389a0214mr5236026oab.49.1708107884746; Fri, 16 Feb 2024 10:24:44 -0800 (PST) Content-Type: multipart/mixed; boundary="------------JZv2Oucc0fxnFsYn08RsO01N" Message-ID: Date: Fri, 16 Feb 2024 12:32:31 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US From: Rob Landley To: Rich Felker , Geert Uytterhoeven Cc: Linux-sh list , musl References: <2d8878fa-c990-e187-9040-934cce908e7c@landley.net> <20240215134941.GE4163@brightrain.aerifal.cx> <20240215164723.GG4163@brightrain.aerifal.cx> <08431a7c-322e-596c-ff46-6b7e0578646d@landley.net> In-Reply-To: <08431a7c-322e-596c-ff46-6b7e0578646d@landley.net> Subject: Re: [musl] FDPIC on sh4? This is a multi-part message in MIME format. --------------JZv2Oucc0fxnFsYn08RsO01N Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 2/16/24 06:25, Rob Landley wrote: > On 2/15/24 10:47, Rich Felker wrote: >> On Thu, Feb 15, 2024 at 03:53:53PM +0100, Geert Uytterhoeven wrote: >>> Hi Rich, >>> >>> On Thu, Feb 15, 2024 at 2:49 PM Rich Felker wrote: >>> > On Thu, Feb 15, 2024 at 04:31:00AM -0600, Rob Landley wrote: >>> > > Is there any easy way to build FDPIC support for sh4 with-mmu? In theory ARM can >>> > >>> > On the userspace toolchain and musl side, yes, I see no reason you >>> > shouldn't be able to build musl for sh4 with fdpic ABI or build a >>> > toolchain for sh4 that defaults to fdpic and has fdpic target-libs. I >>> > just tested passing -mfdpic to sh4-linux-musl-gcc and it seems to >>> > produce correct fdpic code. >>> > >>> > On the kernel side, I'm not sure, but the normal ELF loader should be >>> > able to load fdpic binaries on a system with mmu. It will not float >>> > the data segment separately from text, but doesn't need to because it >>> > has an mmu. If this is no longer working it's a kernel regression; >>> > that's how I always tested sh2eb fdpic binaries on qemu-system-sh4eb. >>> > >>> > > do it, so I tried editing the kconfig BINFMT_ELF_FDPIC dependencies in >>> > > fs/Kconfig.binfmt to move "SUPERH" out of the !MMU list and put it next to ARM, >>> > > switched on the FDPIC loader, and the build broke with: >>> > > >>> > > fs/binfmt_elf_fdpic.o: in function `load_elf_fdpic_binary': >>> > > binfmt_elf_fdpic.c:(.text+0x1b44): undefined reference to >>> > > `elf_fdpic_arch_lay_out_mm' >>> > >>> > It looks like there's an arch-provided function that's conditional on >>> > !MMU in arch/sh but that, now that fdpic loader is intended to be >>> > supported on mmu-ful systems, should be changed to be conditional on >>> > fdpic support (or maybe even unconditional if fdpic can be loaded as a >>> > module). Just look for where it's defined in arch/sh. If it's in a >>> > nommu-specific file it might need to be moved somewhere more >>> > appropriate, or an mmu-ful variant may need to be written and placed >>> > somewhere more appropriate. >>> >>> ARM is the sole architecture that provides elf_fdpic_arch_lay_out_mm(). >> >> Ah, I missed that this was a new mmu-ful only function. So I guess >> something like the ARM one is needed. I'm not clear why this is >> expected to be arch-specific, so it would probably be nice for the >> kernel to provide a generic version that archs can use unless they >> need specific behaviors here, or just make it conditional whether it's >> called at all (only if the arch declares its presence) and use >> defaults otherwise. > > It's in arch/arm/kernel/elf.c, and pretty short. Doesn't LOOK > architecture-specific, although I'm not an expert. (Why SZ_16M instead of > RLIM_STACK? No idea...) arch/sh/kernel/elf.c doesn't exist so I cut and pasted the function into setup.c just to see what would happen... (Question about that file while I'm there: why are calibrate_delay(), generic_mode_pins(), and test_mode_pin() not marked __init? And is marking sh_fdt_init() as __ref equivalent to marking it __init?) The build broke, I fixed it up to at least compile, and my sh2eb fdpic filesystem didn't boot because... Starting init: /bin/sh exists but couldn't execute it (error -8) Exec format error, but I _think_ that's me trying to run a bit endian executable on a little endian kernel build. :) Anyway, to keep you posted, here's the "wrong fix" so far. (Attached because thunderbird "upgraded" itself and broke my wordrap disable plugin.) Rob --------------JZv2Oucc0fxnFsYn08RsO01N Content-Type: text/x-patch; charset=UTF-8; name="sh-fdpic-mmu.patch" Content-Disposition: attachment; filename="sh-fdpic-mmu.patch" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2FyY2gvc2gva2VybmVsL3NldHVwLmMgYi9hcmNoL3NoL2tlcm5lbC9z ZXR1cC5jCmluZGV4IGQzMTc1ZjA5YjNhYS4uZWZmZGE4YjIxMzcwIDEwMDY0NAotLS0gYS9h cmNoL3NoL2tlcm5lbC9zZXR1cC5jCisrKyBiL2FyY2gvc2gva2VybmVsL3NldHVwLmMKQEAg LTQwNCwzICs0MDQsMjggQEAgdm9pZCBfX2luaXQgYXJjaF9jcHVfZmluYWxpemVfaW5pdCh2 b2lkKQogI2VuZGlmCiAJKnAgPSAnXDAnOwogfQorCisjaWYgZGVmaW5lZChDT05GSUdfTU1V KSAmJiBkZWZpbmVkKENPTkZJR19CSU5GTVRfRUxGX0ZEUElDKQorCisjaW5jbHVkZSA8bGlu dXgvcGVyc29uYWxpdHkuaD4KKyNpbmNsdWRlIDxsaW51eC9lbGYtZmRwaWMuaD4KKwordm9p ZCBlbGZfZmRwaWNfYXJjaF9sYXlfb3V0X21tKHN0cnVjdCBlbGZfZmRwaWNfcGFyYW1zICpl eGVjX3BhcmFtcywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgZWxm X2ZkcGljX3BhcmFtcyAqaW50ZXJwX3BhcmFtcywKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB1bnNpZ25lZCBsb25nICpzdGFydF9zdGFjaywKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nICpzdGFydF9icmspCit7CisJc2V0X3BlcnNv bmFsaXR5KChjdXJyZW50LT5wZXJzb25hbGl0eSAmIH5QRVJfTUFTSykgfCBQRVJfTElOVVgp OworCisgICAgICAgIGV4ZWNfcGFyYW1zLT5sb2FkX2FkZHIgPSAweDgwMDA7CisgICAgICAg IGludGVycF9wYXJhbXMtPmxvYWRfYWRkciA9IEVMRl9FVF9EWU5fQkFTRTsKKyAgICAgICAg KnN0YXJ0X3N0YWNrID0gVEFTS19TSVpFIC0gU1pfMTZNOworCisgICAgICAgIGlmICgoZXhl Y19wYXJhbXMtPmZsYWdzICYgRUxGX0ZEUElDX0ZMQUdfQVJSQU5HRU1FTlQpID09IEVMRl9G RFBJQ19GTEFHX0lOREVQRU5ERU5UKSB7CisgICAgICAgICAgICAgICAgZXhlY19wYXJhbXMt PmZsYWdzICY9IH5FTEZfRkRQSUNfRkxBR19BUlJBTkdFTUVOVDsKKyAgICAgICAgICAgICAg ICBleGVjX3BhcmFtcy0+ZmxhZ3MgfD0gRUxGX0ZEUElDX0ZMQUdfQ09OU1RESVNQOworICAg ICAgICB9Cit9CisKKyNlbmRpZgorCg== --------------JZv2Oucc0fxnFsYn08RsO01N--