--- Comment #4 from Richard Biener <rguenth at gcc dot> ---
(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

Reply via email to