Hi,
On 2018-07-09 13:34:44 -0700, Andres Freund wrote:
> after upgrading binutils (from 2.30-22 to 2.30.90.20180705-1) *newly*
> built binaries don't work well with valgrind anymore. Binaries built
> with an older version of binutils, verified by downgrading, continue
> to work well with valgrind.
>
> The stack traces after the upgrade are useless. This both makes using
> valgrind nearly pointless, as well as breaking valgrind suppression
> files (which rely on useful backtraces).
>
> A trivial example is the following:
>
> $ dpkg-query --showformat='${Version}' --show binutils
> 2.30-22
>
> $ cat ~/tmp/uninitialized.c
> int
> main(int argc, char **argv)
> {
> int foo;
>
> if (foo == 3)
> return 0;
> else
> return 1;
> }
>
> $ gcc ~/tmp/uninitialized.c -o uninitialized
> $ valgrind ./uninitialized
> ...
> ==16745== Conditional jump or move depends on uninitialised value(s)
> ==16745== at 0x108609: main (in /home/andres/tmp/uninitialized)
> ..
>
> # dpkg -i *binutils*2.30.90*
>
> $ dpkg-query --showformat='${Version}\n' --show binutils
> 2.30.90.20180627-1
>
> $ gcc ~/tmp/uninitialized.c -o uninitialized
> ...
> ==18603== Conditional jump or move depends on uninitialised value(s)
> ==18603== at 0x109159: ??? (in /home/andres/tmp/uninitialized)
> ==18603== by 0x4CADB16: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so)
> ...
>
> but if I force gold to be used:
> $ gcc -fuse-ld=gold ~/tmp/uninitialized.c -o uninitialized
> $ valgrind ./uninitialized
> ....
> ==18665== Conditional jump or move depends on uninitialised value(s)
> ==18665== at 0x108619: main (in /home/andres/tmp/uninitialized)
>
> so this seems somewhat likely to be related to GNU ld changes, rather
> than a valgrind issue. I haven't yet figured out which of the changes
> between the two versions is to blame
Appears to be an issue in valgrind:
https://bugs.kde.org/show_bug.cgi?id=395682#c9
I'll try to reassign the bug to valgrind.
Greetings,
Andres Freund
