From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 8E7E93858D1E for ; Fri, 28 Jul 2023 05:50:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8E7E93858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1bbc7b2133fso11083235ad.1 for ; Thu, 27 Jul 2023 22:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690523449; x=1691128249; 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=neB55dLxLj5kUOinXckR+7NXwiQjNprD/XyU6o9dwuo=; b=JyUzeacImKj6+FoTZfrkFhKcs8denDRiP+79R+o8AfVUbv8Q3G9Y1CLVtgs06tMTpx utUHITMr8q+cKWj2lCNWTKvRr0jIOZe2eim/S88+M92DHysAOFnzkjXoUDl8t2QLS2Xg +pqFYurWfynb009/A9muwOGQZGkn1l9mUfOhhdfjSBq0Zzyxae41fD6kA7hVASC3qQFV wEgEUkn6tqS/dan8+N34bE4vK9A4phzr1bbMCul8Awk7tOpM1qViRZw1EkrX5rpczQL1 F0KenOAYpd1IIHdg0nWldgwf84uJh2AJg8uRiUxNoTezQrEWuZ35naAu+CergZM595uj muJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690523449; x=1691128249; 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=neB55dLxLj5kUOinXckR+7NXwiQjNprD/XyU6o9dwuo=; b=adzGPC2BIOoCoYRCeV/ZVmaWv5W9BhwxpbeMONch2BKM2n/8GZ+XaAaETa2W1yqWbW 020sWYUNuLFIUtY6HEKor43AHoo1ejh+oIs7mQpTmVjNwwFlbz18pitjl9Y5bMG6vrOT YeZAoRPYS87hvmWpd/5WA7O81GtRPC3PxUesrBPDypn1noK3SJufax0S6w9SNK1FUXTx ED0g0aRhbi4kQen17711lzd5W3mkCSbIxnqKg1kWIBphbPsmLrJTsKGyubyEGh8QS/0d 0jn87nbxqca7dqV4rr6j9bkNzXrYBeBYtj6gpQ2yec0M+acdP6SUPc7Q6bEV3h1evopo wYrw== X-Gm-Message-State: ABy/qLYBKvBtndJgehYrOIPw8nRcW+tHEnwFWNZcBSvgld820DJgdpBZ fIKWmJHNR7QpFB2u/hCRb0KAiwhrMHZfo2Tc5Ut1r2q2uAQ6LsMB X-Google-Smtp-Source: APBJJlEDKVwqNAuxTpUCALBRJiIE9m5wzazVZgCk27LYMzOSwX/gBTILECbbfZ2cBBVGbjq4t50yMx5TgMxxIRoLGFE= X-Received: by 2002:a17:902:9b88:b0:1b8:3cb8:7926 with SMTP id y8-20020a1709029b8800b001b83cb87926mr677768plp.23.1690523449517; Thu, 27 Jul 2023 22:50:49 -0700 (PDT) MIME-Version: 1.0 References: <20230630064559.2282365-1-yunqiang.su@cipunited.com> In-Reply-To: From: YunQiang Su Date: Fri, 28 Jul 2023 13:50:38 +0800 Message-ID: Subject: Re: [PATCH] MIPS: N64, mark .interp as INITIAL_READONLY_SECTIONS To: "Maciej W. Rozycki" Cc: YunQiang Su , binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Maciej W. Rozycki =E4=BA=8E2023=E5=B9=B47=E6=9C=8828=E6= =97=A5=E5=91=A8=E4=BA=94 13:29=E5=86=99=E9=81=93=EF=BC=9A > > On Fri, 30 Jun 2023, YunQiang Su wrote: > > > In ld/emulparams/elf64bmip-defs.sh, there is no .interp, which make > > the .interp section appears after some other less important sections. > > Let's add it, and mark it as INITIAL_READONLY_SECTIONS, just like > > O32/N32 do. > > > > This changes fixes ld/pr23658-2. > > It would have helped with the review if the actual difference between th= e > output expected by the test case and one produced was given along with th= e > submission, perhaps in the discussion section. > OK. I will do like this. > Without that I had to bend backwards to make this test case run with n64 > MIPS at all and see what is going on here as I don't have a compiler > available for OpenBSD, which is my reference target for n64 verification. Ohh, you are right: we need a compiler for OpenBSD. I will work on it. For other N64 targets, you can try Debian's cross toolchain. If you are using Debian or Ubuntu, you can use apt install g++-multilib-mips64el-linux-gnuabi64 apt install g++-multilib-mips64-linux-gnuabi64 or apt install g++-multilib-mipsisa64r6el-linux-gnuabi64 apt install g++-multilib-mipsisa64r6-linux-gnuabi64 to get the cross toolchain for MIPSn64. > This revealed a minor discrepancy only between the output produced: > > 03 .MIPS.abiflags .MIPS.options .dynamic .hash .dynsym .dynstr .te= xt .interp .note.4 .note.1 .note.2 .note.3 > > vs expected: > > +[0-9]+ +\.interp \.note.4 \.note.1 \.note.2 \.note.3.* > > and made me question whether the test case shouldn't be relaxed instead. > Eventually I realised this is actually a fix for a regression back from > 2006, so I chose to give your change a go-ahead, even though clearly the > current arrangement is good enough not to have caused any issues through > 17 years. > > Overall compiled tests are hard to run in a multi-target environment > where compilers for all the exotic configurations are not necessarily > available and therefore these tests receive less attention. As compiler > configurations vary these tests may even produce incorrect results despit= e > no actual issue being present with binutils. They're a compromise really > for issues discovered in the past for which no effort could have been > allocated to prepare specific per-target tests that rely on tools coming > with binutils only. > > It also means we need proper coverage for section ordering, as it would > have prevented this bug from having been introduced in the first place. > > > ld/ChangeLog: > > * emulparams/elf64bmip-defs.sh: mark .interp as > > INITIAL_READONLY_SECTIONS. > > * testsuite/ld-mips-elf/pie-n64.d: adjust addresses. > > We'd best avoid code duplication we have here, which leads to situations > exactly such as this one. But that'd be for a larger rewrite. Meanwhile > your change seems good to me as an interim fix, with typos fixed in the > change description. > > As I have observed above a test case is needed, so I have now pushed an > updated version including a suitable set of tests, as recorded here: > . > > In the future please try to come up with testsuite cases for bug fixes > where feasible. I appreciate that making a test case often takes more > effort than the bug fix itself, but we need these tests so as not to > reintroduce similar issues in the future, such as e.g. with a rewrite I > have suggested above. > > Thank you for your contribution. > > Maciej --=20 YunQiang Su