--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Mark Wielaard from comment #3)
> (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
> 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
So the error must be visible with readelf as well. Can you upload the
valgrind binary somewhere (does the issue only reproduce with separate
debug and/or dwz?)?
It's also a quite odd error unless the whole .debug_line section looks