Re: [PATCH] Revert "x86_64: Suppress false positive valgrind error"

[Florian Weimer <fweimer@redhat.com>]

* H. J. Lu:

> On Sat, Apr 13, 2024 at 8:27 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> On Sat, Apr 13, 2024 at 8:20 AM Florian Weimer <fweimer@redhat.com> wrote:
>> >
>> > * H. J. Lu:
>> >
>> > > On Sat, Apr 13, 2024 at 8:03 AM Florian Weimer <fweimer@redhat.com> wrote:
>> > >>
>> > >> * H. J. Lu:
>> > >>
>> > >> > On Sat, Apr 13, 2024 at 7:49 AM Florian Weimer <fweimer@redhat.com> wrote:
>> > >> >>
>> > >> >> This reverts commit a1735e0aa858f0c8b15e5ee9975bff4279423680.
>> > >> >>
>> > >> >> The test failure is a real valgrind bug that needs to be fixed before
>> > >> >> valgrind is usable with a glibc that has been built with
>> > >> >> CC="gcc -march=x86-64-v3".  The valgrind fix addresses the observed
>> > >> >> test failure as well.
>> > >> >>
>> > >> >> Upstream bug: <https://bugs.kde.org/show_bug.cgi?id=485487>
>> > >> >>
>> > >> >> Tested on x86_64-linux-gnu with and without CC="gcc -march=x86-64-v3".
>> > >> >> The elf/tst-valgrind-smoke tests again fails with an unpatched valgrind,
>> > >> >> and the proposed upstream patch fixes it.  (Apparently, valgrind
>> > >> >> matches on soname, and not the file name, which is ld.so in the test.)
>> > >> >
>> > >> > Please clarify that your patch fixes the glibc valgrind test by not using
>> > >> > strcmp-avx2.S in the valgrind test.
>> > >>
>> > >> Sorry, clarify where?  In the commit message here?  On the upstream bug?
>> > >
>> > > In the glibc commit message.
>> > >
>> > >> My valgrind patch replaces the strcmp implementation in ld.so with its
>> > >> own.
>> > >>
>> > >
>> > > Please mention it in the glibc commit message.
>> >
>> > Okay, I'll send a v2.
>> >
>> > Could someone proficient in x86-64 assembly have a look at my strcmp
>> > implementation?
>>
>> Can you adapt sysdeps/i386/i686/strcmp.S for valgrind?
>>
>
> You can use sysdeps/x86_64/strcmp.S from glibc 2.10:

True.  It's mostly a licensing matter at this point.  The copyright
notice is longer than the assemly …

Florian