https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- 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 > <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 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 garbled.
