[PATCH] ld: Require GCC 8.0 for p_align-1.c tests

[H.J. Lu]

On Mon, Jan 17, 2022 at 5:51 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 17.01.2022 14:44, H.J. Lu wrote:
> > On Mon, Jan 17, 2022 at 2:38 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 14.01.2022 15:14, H.J. Lu wrote:
> >>> On Fri, Jan 14, 2022 at 6:08 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 14.01.2022 15:02, H.J. Lu wrote:
> >>>>> On Fri, Jan 14, 2022 at 5:40 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> On 14.01.2022 14:03, H.J. Lu wrote:
> >>>>>>> On Fri, Jan 14, 2022 at 12:27 AM Jan Beulich <jbeulich@suse.com> 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 <ckennelly@google.com>
> >>>>>>> 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.