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 D55B62A3ED for ; Fri, 16 Feb 2024 13:18:12 +0100 (CET) Received: (qmail 7958 invoked by uid 550); 16 Feb 2024 12:15:03 -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 7925 invoked from network); 16 Feb 2024 12:15:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley-net.20230601.gappssmtp.com; s=20230601; t=1708085878; x=1708690678; darn=lists.openwall.com; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=UXxLHIQnXIA5qnxPoCMUjtbPVmRBO3dP7QzVREvGIW4=; b=KmAoyIilteUF+FDxh2GxHONgPIjSYJSqGLQ8HtaTXrI4VKpb8AOL4znI+UoGAidzhY 4aTPEbe2eiHx8FjklIZS2pusK0RXf3ZDfM1eQF7s8d+jLXthObW1DL5aJpShcrKXCIxU eRYulFQrqO/+JMAZjU1nK6BpyP1DR6yOeejzfqSer9Y3NfQrkKOtwAhBtGjI4uDCdONK YolazBCepF/LoOkJ11i9BHBPTdw3e38J/cq3zSdTFIxEjD5uvyB/MMTW16NxNtUTrTZ9 UN3sHbFTQnjRQczz+u5CbN50RtqH+4VY5iUh3z/l0QhqLiz7Lh3WJqK9EeDolVWech7P c+Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708085878; x=1708690678; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UXxLHIQnXIA5qnxPoCMUjtbPVmRBO3dP7QzVREvGIW4=; b=d6Asx09H754d9CbBO2cJPjQH+m/61uiadKtMWtODtJCKiW232OToJozgKlKVHKPkM1 TkPQArpg5Y8nfpLR2CG2ReEsYiNXBckwJdjQ2QBVmLSgFKzpYZmbn3ZbZgWrcges7RXB WU6qotpn5GGpeE5n07D0+/1gthH+MQYlXZQElpckwX4sgfPQa/JYkY2XTLJmmInxa8Vc dqVxWl3F4F0Yy6xudNC62M6zVpPNgbmHAEF03Ih312p3yud97fpYJqZz8I3E233zEWjE vOkk3gbGYAAP2CZp6V7SeIFck9NbmfeL/V+ZSW8JxELjXAo2Ztn1Yd8IgvycRGCtNTjK 3sdA== X-Forwarded-Encrypted: i=1; AJvYcCXInnevBdwsydlVyM2r2kfcGKAfU4jkn/Okjrwy2t2lyHtWE1TBUjE8tVttfcVI6AIXBhoR62MwB7nmzbXlFqYeVsN7bf2pTA== X-Gm-Message-State: AOJu0YzMf84urMJyg5hzT9YQHjro2a8UQXEJj1aAwsf+TS2ICshnCLlc gfK51UqbT5ekGYjkrKFkCxT1IbdUz+ExNhpiQXt6ZH7wIMaPyoWkcoBUUe2N4XY= X-Google-Smtp-Source: AGHT+IFLcjMFF+pBwek4PErIKA3wi7vGqpzD8lmZCW4tYcvATeB7kIrlvIwqzKz0Djbb0JCP75jbeQ== X-Received: by 2002:a9d:774d:0:b0:6e2:e955:c718 with SMTP id t13-20020a9d774d000000b006e2e955c718mr4545563otl.1.1708085878000; Fri, 16 Feb 2024 04:17:58 -0800 (PST) Message-ID: <08431a7c-322e-596c-ff46-6b7e0578646d@landley.net> Date: Fri, 16 Feb 2024 06:25:44 -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 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> From: Rob Landley In-Reply-To: <20240215164723.GG4163@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [musl] FDPIC on sh4? 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...) #if defined(CONFIG_MMU) && defined(CONFIG_BINFMT_ELF_FDPIC) void elf_fdpic_arch_lay_out_mm(struct elf_fdpic_params *exec_params, struct elf_fdpic_params *interp_params, unsigned long *start_stack, unsigned long *start_brk) { elf_set_personality(&exec_params->hdr); exec_params->load_addr = 0x8000; interp_params->load_addr = ELF_ET_DYN_BASE; *start_stack = TASK_SIZE - SZ_16M; if ((exec_params->flags & ELF_FDPIC_FLAG_ARRANGEMENT) == ELF_FDPIC_FLAG_INDEPENDENT) { exec_params->flags &= ~ELF_FDPIC_FLAG_ARRANGEMENT; exec_params->flags |= ELF_FDPIC_FLAG_CONSTDISP; } } #endif Oddly, it's NOT in arch/arm64. Does the 64 bit arch pull in bits of the 32 bit one, or is this only supported for 32 bit arm? Rob