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.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 D9C2B21D41 for ; Thu, 15 Feb 2024 11:23:30 +0100 (CET) Received: (qmail 11896 invoked by uid 550); 15 Feb 2024 10:20:23 -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 11861 invoked from network); 15 Feb 2024 10:20:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley-net.20230601.gappssmtp.com; s=20230601; t=1707992596; x=1708597396; darn=lists.openwall.com; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=yK9BzjI4EuWJ5oP8jb5JKbLdn6UVkMpasNFQq6RGWkg=; b=2CDwEBN+0ZaIsd1g+amFhHpZVanaKG1Ncuj7cEy24uqCt5WiQ8CaWD5HSI/LaElw8d MA1Z0KO5bS2X4vVOX8f6H9PhET6ButOqpSeBXWpGVOER9V9+gxLt30ovfyc/kpckSrXD BlHh2oanOBK/iSYS8ZYupgIsLuB+MB6bPmIqeU5Pa7sQbaCBC8ZAjTBOtSj2ym7UEI+3 OhEk8G7Ung2ZMCsNhZgaEU4eeVb4EiikzHiRR5rOApuptxII8q4qI1OtfByQ6JrQOJ23 QazF62+OAcOZvp+05rexbTjbSLyWFzaNcuuc467MhLP1Is2CjZ93CvoXYVT+reyU9XJH V8JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707992596; x=1708597396; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=yK9BzjI4EuWJ5oP8jb5JKbLdn6UVkMpasNFQq6RGWkg=; b=kqpgxhl4Q67QNJQ0fOOGN1PNA9cormG9VoOzicMfNAuINh44DXl2Da0px9k4NFaI40 mZlhZZ0+cvnrw5Te9E5Z7+svCLgw4iWK4D8rt235zXvJjFaX7ChhNoQyEIJPUgSfNJAX Vuyv01JH3y31hjmnmdR9DKOO9yZ+tQVx9grEpPb91mnamds76YDIVMrKgmIV2rHhMMri CglIQObyT43hnepBJvGFG8sTaRs7tQqQ0RoMBYzmlFBIAiuWend0PXixW8V8/pxWbJbu H2nFPWKE3AaQSs5/R7JcHo1bi9Oazm9fY/oUneqF2j22ifv+ZlxV/DWhkKl8LxPPfNvP 0BUg== X-Forwarded-Encrypted: i=1; AJvYcCWiW3BZAATwKtmn+BT9li3JPdYDf/Cuu4KYw4ZTxdPIABCs1qPQpbEsMnC1xsj2z6+JKN0Q1Xw8nzH/57RLIf1RsJa8qofl3w== X-Gm-Message-State: AOJu0Yz4U77nO7G4QfvasF311y39L6nqYMitUjaKRY3QVCMe3BTs6R3y uzRkXntz2y/I4s7LUDch1/Ga54OWCAQE7/TFwB/h7ax/O+tQLw5COKxEbxHNSwo= X-Google-Smtp-Source: AGHT+IFD7LwiLb6QhpY0M1rggPrmocnFFg4PMfAFuALLj0tyUXGpFcrXfy9O0w+Fd3aiWNvCstQBoA== X-Received: by 2002:a05:6830:18d0:b0:6e2:ed2e:3a9 with SMTP id v16-20020a05683018d000b006e2ed2e03a9mr1078470ote.37.1707992595987; Thu, 15 Feb 2024 02:23:15 -0800 (PST) Message-ID: <2d8878fa-c990-e187-9040-934cce908e7c@landley.net> Date: Thu, 15 Feb 2024 04:31:00 -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: Linux-sh list , musl From: Rob Landley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [musl] FDPIC on sh4? Is there any easy way to build FDPIC support for sh4 with-mmu? In theory ARM can 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' Backstory: I want to test nommu under qemu, and my existing tests are all using qemu-system-$TARGET builds with musl-libc toolchains built by musl-cross-make. I have a nommu test environment on real (FPGA) hardware, using an sh2 fdpic toolchain built from musl-cross-make using gcc 9.4.0, but that's not part of my normal "cursor up and hit enter" fully automated regression testing that builds and launches qemu instances with a prepared filesystem that launches tests from the init script and does "expect" style processing on the serial console connected to qemu's stdin/stdout. Testing on the FPGA board requires repeatedly removing and inserting sd cards, so I don't do it nearly as often, and right now that's my ONLY nommu test environment. I want to get a qemu-system-something running nommu. Since musl-libc only supports fdpic, this limits my choices to the intersection of Linux's FDPIC support: $ grep FDPIC -m1 -A3 fs/Kconfig.binfmt config BINFMT_ELF_FDPIC bool "Kernel support for FDPIC ELF binaries" default y if !BINFMT_ELF depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) And gcc's FDPIC support: $ dirname $(grep -irl fdpic gcc/config) | sort -u gcc/config/arm gcc/config/bfin gcc/config/frv gcc/config/sh Ever since linux threw blackfin and frv overboard to lighten the load, this means gcc can produce fdpic output for exactly two targets that Linux supports: arm and superh. (No, riscv is not joining them. I emailed about https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/ZjYUJswknQ4/m/QnTEfur4BwAJ yesterday and was told "Sadly that project didn't go beyond the ABI design phase." so riscv-fdpic is _not_ currently in development.) In theory arm can use the FDPIC loader on a with-mmu kernel, but the arm configure doesn't have a way to combine "musl" with the magic "uclinuxfdpiceabidoodahdoodah" blob because their matches keep looking like: "arm*-*-uclinuxfdpiceabi" and "*-linux-musl*" which aren't compatible. (If that first one didn't have the extra dash...) Alas arm-unknown-musl-uclinuxfdpiceabi makes binutils go "checking target system type... Invalid configuration `armv7m-linux-musl-uclinuxfdpiceabi': machine `armv7m-linux-musl' not recognized". So I was thinking "maybe I can build an sh4 kernel with an sh4 compiler, and build a userspace with the sh2eb compiler" (this is unlikely to work because every sh4 system I've ever used is little endian and the j-core guys inexplicably chose big endian, but I can burn that bridge when I come to it...) But that's how I hit the "enabling FDPIC on with-mmu only works with arm, nothing else" issue above. And that's incompatible with selecting musl support. Rob PS. the sh2 fdpic toolchain in musl-cross-make doesn't reproduce with the newest "supported" gcc (11.2.0) because: In file included from libstdc++-v3/libsupc++/eh_call.cc:32: libstdc++-v3/../libgcc/unwind-pe.h: In function 'const unsigned char* read_encoded_value_with_base(unsigned char, _Unwind_Ptr, const unsigned char*, _Unwind_Ptr*)': libstdc++-v3/../libgcc/unwind-pe.h:270:25: error: '_Unwind_gnu_Find_got' was not declared in this scope 270 | result += _Unwind_gnu_Find_got ((_Unwind_Ptr) u); Which has been broken ever since musl-cross-make's newest last commit almost 2 years ago.