2.36 pre-release

[Mark Wielaard]

Hi,

On Mon, 2022-07-25 at 15:41 +0200, Florian Weimer via Libc-alpha wrote:
> * Paul Zimmermann:
> 
> >        Dear Florian,
> > 
> > > > on my i5-4590 with gcc 11.3.0, I get one failure when I
> > > > configure with
> > > > -march=native:
> > > > 
> > > > Summary of test results:
> > > >       1 FAIL
> > > >    5084 PASS
> > > >      77 UNSUPPORTED
> > > >      18 XFAIL
> > > >       4 XPASS
> > > > 
> > > > FAIL: elf/tst-valgrind-smoke
> > > > 
> > > > zimmerma@tomate:/localdisk/zimmerma/glibc/build-fma$ cat
> > > > elf/tst-valgrind-smoke.out 
> > > > /usr/bin/valgrind
> > > > /lib64/ld-linux-x86-64.so.2
> > > > bin: /localdisk/zimmerma/glibc/build-fma/elf/valgrind-test
> > > > ld.so: /localdisk/zimmerma/glibc/build-fma/elf/ld.so
> > > 
> > > Would you please check if there is output to stderr, e.g. when
> > > running
> > > 
> > >   make t=elf/tst-valgrind-smoke test
> > > 
> > > ?  It's possible that valgrind does not support everything
> > > required by
> > > -march=native.
> > 
> > ok course, here you are:
> > 
> > zimmerma@tomate:/localdisk/zimmerma/glibc/build-fma$  make
> > t=elf/tst-valgrind-smoke test
> > ...
> > ==2457609== Conditional jump or move depends on uninitialised
> > value(s)
> > ==2457609==    at 0x12A118: strcmp (strcmp-avx2.S:462)
> > ==2457609==    by 0x1125B4: _dl_name_match_p (dl-misc.c:69)
> > ==2457609==    by 0x10FE43: _dl_map_object (dl-load.c:1971)
> > ==2457609==    by 0x122124: map_doit (rtld.c:647)
> > ==2457609==    by 0x11F8C5: _dl_catch_exception (dl-error-
> > skeleton.c:208)
> > ==2457609==    by 0x11F95E: _dl_catch_error (dl-error-
> > skeleton.c:227)
> > ==2457609==    by 0x12261E: do_preload (rtld.c:822)
> > ==2457609==    by 0x12340F: handle_preload_list (rtld.c:898)
> > ==2457609==    by 0x12630F: dl_main (rtld.c:1857)
> > ==2457609==    by 0x1217BE: _dl_sysdep_start (dl-sysdep.c:140)
> > ==2457609==    by 0x1231E1: _dl_start_final (rtld.c:497)
> > ==2457609==    by 0x1231E1: _dl_start (rtld.c:584)
> > ==2457609==    by 0x122007: ??? (in
> > /localdisk/zimmerma/glibc/build-fma/elf/ld.so)
> > ==2457609== 
> 
> I think we need more intercepts for ld.so, similar to what was added
> here for strncmp:
> 
>   iconv_open causes ld.so v2.28 and later to execute optimised
> strncmp
>   which confuses memcheck
>   <https://bugs.kde.org/show_bug.cgi?id=434764>
> 
> With some recent x86-64 changes, -march=native affects the choice of
> the
> baseline string function implementation that gets used in ld.so,
> which is why this wasn't visible before.

Yes, that was this commit btw:
https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=947388eb043ea1c44b37df94046e1eee790ad776;hp=277f10d523bf7cfac4d0c6acf78e9949ae072e7f

If this is something that distros are likely to use then we need
something like the above to intercept strcmp in ld.so.

Or is this just when someone hand-compiles glibc for their specific
machine? Then maybe it only should go into a hand compiled valgrind
too?

If possible please file a valgrind bug for this:
https://bugs.kde.org/enter_bug.cgi?product=valgrind

> You also need to upgrade to get proper rseq support in valgrind (but
> this isn't why this test fails).

rseq syscall "support" is in valgrind 3.19.0 (and some distros
backported to 3.18.1). Where "support" simply means it returns ENOSYS
without printing the warning.

Thanks,

Mark