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=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 DCE152370D for ; Thu, 15 Feb 2024 15:54:22 +0100 (CET) Received: (qmail 21592 invoked by uid 550); 15 Feb 2024 14:51:15 -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 21559 invoked from network); 15 Feb 2024 14:51:15 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708008848; x=1708613648; 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=tv8W02IwoAGjajQhC8ew+i9EdxhvajI92aHSXZwEPIQ=; b=OrJpfe7yjwxh+dLBkKZ6+zUkVv9LrtfbmSIZhJjUj+Ihz/IhmcfKoa05TqbORh9Dmt jfGsVFy8ZGTv2Jdw3iJ2N6n3wQNaL5a7e+69cTIvJ/U9L8uhH6+PZh8GtOqMUj7NG9ll egUS14YINwZsxsoQOnwKqe9s+2/y7DNJGSb9T6/AKXqH1resSMZNpbqz4SGHXAVR33ta bbz8qdyQcHr9RWCZHaROSVukkIkc4n8REaXoXcXerE5L1OwDb6XAoi9/LB5p47xLZEvP rmJzciPn50mr0ofWxBGW1B8z2sfajbQ1B+zp25olTUdSIFa6CdvtN4rPAN4+BujXKftc vmlg== X-Forwarded-Encrypted: i=1; AJvYcCXYnqrSGYpm5zq22PvSvLziAvGv/daMDGdzfB0K7tJEDsIJ0Yuczd+iKC40qw13A606QXkQDjBk2TRmggsDJgg5WpoqWWUMNg== X-Gm-Message-State: AOJu0YxmUR+y2CAYKl4tzMmKYEmNXxT6tUkAUAHt99uHFr1M653MGEON tyfuMSGG3tUYaxEPO5O45r+qanAQy4issav11/L6NiZKIffv3fwS+8P4+xBASS3fKw== X-Google-Smtp-Source: AGHT+IEgM7lkKu1CLcG5UwRGZm11dPnGaoBxxGlaalCKCxGj4z7sZ92uhinDwnVN9VNRcz2KQn1c+g== X-Received: by 2002:a0d:ca8e:0:b0:607:ad25:7ea with SMTP id m136-20020a0dca8e000000b00607ad2507eamr1846959ywd.39.1708008848049; Thu, 15 Feb 2024 06:54:08 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWLMBE9pplcrEILvMNTZhUq2CwO+MrCIq8JL9QwhYRTWJgtgzx+qxrO+ycAY2YRfhB8PSIe3hWjWXh5P4Nkmp/MFN17Fle1sw== X-Received: by 2002:a81:6d48:0:b0:607:cefd:3bdf with SMTP id i69-20020a816d48000000b00607cefd3bdfmr1899039ywc.24.1708008847633; Thu, 15 Feb 2024 06:54:07 -0800 (PST) MIME-Version: 1.0 References: <2d8878fa-c990-e187-9040-934cce908e7c@landley.net> <20240215134941.GE4163@brightrain.aerifal.cx> In-Reply-To: <20240215134941.GE4163@brightrain.aerifal.cx> From: Geert Uytterhoeven Date: Thu, 15 Feb 2024 15:53:53 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Rich Felker Cc: Rob Landley , Linux-sh list , musl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] FDPIC on sh4? Hi Rich, On Thu, Feb 15, 2024 at 2:49=E2=80=AFPM 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 theor= y 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(). Gr{oetje,eeting}s, Geert --=20 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= .org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds