From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 6F10C385802F for ; Mon, 17 Jan 2022 13:55:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6F10C385802F Received: by mail-pg1-x529.google.com with SMTP id c5so10944683pgk.12 for ; Mon, 17 Jan 2022 05:55:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CMEEbaXCObjE5Sv/Q/CTl4UHUa9o/HLeSDwbjR1eczc=; b=zoRI5KFub4ea9FmiGgX9boezQKCkioYXi02RsN+iYFHj8ky18JtUlPzPTV8R3ati+W 2wvAuwPcTmUO4wFGjLH0zq9Z6RX+ycCU9hSxDkPBrpzlqSNdA124MFoYm5TGVZ5TV3Xh BC8L/FCEh0Lk5DL0nAWgr5O8jkOBaXdzcWIE8myZz4KgtEzJQ2VE9GeoQ4V1WcUuNnVd gZn+O+kV5XubGGakak32jEQJbGBNFXYfbktvCP7mFjs/wYtRvxliUo8BI03llEmYZeej RNxq67jJJiBH9scb5ZXo6Us/EcOBg4VC48iY+5l6Al5lxApL2FL9jKIQg/LMozWmeRU9 GpEg== X-Gm-Message-State: AOAM531nxja9zW8Kbq5Yuz5nzaRGypOM3YhBC/byW5tEDR19GZBErWhu jvF6fioONe7K5JvuOB1EKoJQj3tcYJigjMMp4ND7Oxe5 X-Google-Smtp-Source: ABdhPJypVgYTL0FyfYdOWM80Ba6nktcQAuiGclhhkAl+153OiOnFk6wmUtAUkMP0SFgedu62dCWfMjSq+gffNm6O/40= X-Received: by 2002:a05:6a00:234e:b0:4ae:2e0d:cc68 with SMTP id j14-20020a056a00234e00b004ae2e0dcc68mr21190257pfj.60.1642427719371; Mon, 17 Jan 2022 05:55:19 -0800 (PST) MIME-Version: 1.0 References: <20211229193949.146079-1-hjl.tools@gmail.com> <11e134a2-1ee7-bec4-fa03-1d76609923f7@suse.com> <5843914b-e666-3c55-2e5b-5b320d55cf51@suse.com> <1d8309a8-434c-f4e5-1c48-b16229b16489@suse.com> <62989164-2784-07f0-ea30-9000c9c9eb6f@suse.com> In-Reply-To: <62989164-2784-07f0-ea30-9000c9c9eb6f@suse.com> From: "H.J. Lu" Date: Mon, 17 Jan 2022 05:54:43 -0800 Message-ID: Subject: Re: [PATCH] ld: Require GCC 8.0 for p_align-1.c tests To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3022.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2022 13:55:22 -0000 On Mon, Jan 17, 2022 at 5:51 AM Jan Beulich wrote: > > On 17.01.2022 14:44, H.J. Lu wrote: > > On Mon, Jan 17, 2022 at 2:38 AM Jan Beulich wrote: > >> > >> On 14.01.2022 15:14, H.J. Lu wrote: > >>> On Fri, Jan 14, 2022 at 6:08 AM Jan Beulich wrote: > >>>> > >>>> On 14.01.2022 15:02, H.J. Lu wrote: > >>>>> On Fri, Jan 14, 2022 at 5:40 AM Jan Beulich wrote: > >>>>>> > >>>>>> On 14.01.2022 14:03, H.J. Lu wrote: > >>>>>>> On Fri, Jan 14, 2022 at 12:27 AM Jan Beulich wrote: > >>>>>>>> > >>>>>>>> On 29.12.2021 20:39, H.J. Lu via Binutils wrote: > >>>>>>>>> --- a/ld/testsuite/ld-elf/linux-x86.exp > >>>>>>>>> +++ b/ld/testsuite/ld-elf/linux-x86.exp > >>>>>>>>> @@ -185,6 +185,42 @@ run_ld_link_exec_tests [list \ > >>>>>>>>> "" \ > >>>>>>>>> "tmpdir/indirect-extern-access-2.so" \ > >>>>>>>>> ] \ > >>>>>>>>> + [list \ > >>>>>>>>> + "Run p_align-1a without PIE" \ > >>>>>>>>> + "$NOPIE_LDFLAGS" \ > >>>>>>>>> + "" \ > >>>>>>>>> + { p_align-1.c } \ > >>>>>>>>> + "p_align-1a" \ > >>>>>>>>> + "pass.out" \ > >>>>>>>>> + "$NOPIE_CFLAGS" \ > >>>>>>>>> + ] \ > >>>>>>>>> + [list \ > >>>>>>>>> + "Run p_align-1b with PIE" \ > >>>>>>>>> + "-pie" \ > >>>>>>>>> + "" \ > >>>>>>>>> + { p_align-1.c } \ > >>>>>>>>> + "p_align-1b" \ > >>>>>>>>> + "pass.out" \ > >>>>>>>>> + "-fpie" \ > >>>>>>>>> + ] \ > >>>>>>>>> + [list \ > >>>>>>>>> + "Run p_align-1c with -Wl,-z,max-page-size=0x1000 without PIE" \ > >>>>>>>>> + "$NOPIE_LDFLAGS -Wl,-z,max-page-size=0x1000" \ > >>>>>>>>> + "" \ > >>>>>>>>> + { p_align-1.c } \ > >>>>>>>>> + "p_align-1c" \ > >>>>>>>>> + "pass.out" \ > >>>>>>>>> + "$NOPIE_CFLAGS" \ > >>>>>>>>> + ] \ > >>>>>>>>> + [list \ > >>>>>>>>> + "Run p_align-1d with -Wl,-z,max-page-size=0x1000 with PIE" \ > >>>>>>>>> + "-pie -Wl,-z,max-page-size=0x1000" \ > >>>>>>>>> + "" \ > >>>>>>>>> + { p_align-1.c } \ > >>>>>>>>> + "p_align-1d" \ > >>>>>>>>> + "pass.out" \ > >>>>>>>>> + "-fpie" \ > >>>>>>>>> + ] \ > >>>>>>>>> ] > >>>>>>>> > >>>>>>>> The two PIE variants of this also fail for me on glibc 2.26. Looks > >>>>>>>> like LOAD segments' alignment isn't being honored there, at least > >>>>>>>> not if it's as big as it is here. > >>>>>>>> > >>>>>>> > >>>>>>> The PIE alignment needs the kernel fix: > >>>>>>> > >>>>>>> commit ce81bb256a224259ab686742a6284930cbe4f1fa > >>>>>>> Author: Chris Kennelly > >>>>>>> Date: Thu Oct 15 20:12:32 2020 -0700 > >>>>>>> > >>>>>>> fs/binfmt_elf: use PT_LOAD p_align values for suitable start address > >>>>>> > >>>>>> Well, then the test needs to be skipped if that fix is not in place. > >>>>>> After all you're testing binutils behavior here, not kernel or libc one. > >>>>>> I'm running a variety of (largely up-to-date) kernels on all of my > >>>>>> systems. But it looks like our kernel folks decided against backporting > >>>>>> this particular change. And I don't think you expect people to remember > >>>>>> to run the testsuite only on top of "certain" kernels? > >>>>> > >>>>> Care to submit a patch? > >>>> > >>>> I have no idea what to check for. I would really expect you to fix such > >>>> an issue (or really two of them, considering the other problem) recently > >>>> introduced by you. > >>> > >>> What compiler are you using on the broken kernel? > >> > >> gcc 7.4.1 > >> > >> No idea how that matters, though. > > > > Try this. > > I can see that this might help with the other problem I did report, but I > don't see how gcc version and kernel in use would correlate. I guess I > could build binutils on that box with gcc 11, and then the kernel still > wouldn't do what you expect it to do. Much like I could continue using > gcc 7 and use a newer kernel, and then the test would be skipped for no > reason. > Then don't do it. > What I don't understand is why this needs to be a "run" test in the first > place. You're only after checking that the produced binary is correct, > aren't you? The run test is the most reliable way to test it. It can catch regressions in GCC and kernel. -- H.J.