https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #3 from Mark Wielaard <mark at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Err, but isn't this interpreting the dwarf from 'date'? So doesn't this
> mean that valgrind is "miscompiled" with --enable-lto rather than wrong
> debug?
The error message isn't very clear, but valgrind also reads its own code/binary
(which is inserted into the process), which is build with LTO. It is that
library that has the wrong line numbers. Which can also be seen in gdb:
./install/bin/valgrind -q date ==48528== warning: Can't handle line info
entry with line number 177277754 greater than 1048575 ==48528== (Nb: this
message is only shown once) ==48528== warning: Can't handle inlined call info
entry with line number 177277750 greater than 1048575 ==48528== (Nb: this
message is only shown once)
#### Double check that valgrind debug info reader is correct:
gdb ./.in_place/memcheck-amd64-linux
Reading symbols from ./.in_place/memcheck-amd64-linux...
(gdb) info line guest_amd64_toIR.c:177277754 Line number 177277754 is out
of range for "priv/guest_amd64_toIR.c".
Line 177277754 of "priv/guest_amd64_toIR.c" starts at address 0x58069001
<dis_ESC_0F__SSE4+17> and ends at 0x58069005 <dis_ESC_0F__SSE4+21>.
(gdb)
You can also try:
(gdb) disass /s dis_ESC_0F__SSE4
and you zillions of useless lines.
If needed, you can ask valgrind to show more info about what it is
doing/reading by doing e.g.
./install/bin/valgrind -v -v -v -v -d -d -d -d --debug-dump=line date |&
tee d.out
