[Bug lto/94311] LTO produces line info entries with invalid line numbers

[mark at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311

Mark Wielaard <mark at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #5 from Mark Wielaard <mark at gcc dot gnu.org> ---
I can no longer replicate the issue of the bad line numbers with gcc (GCC)
10.1.1 20200507 (Red Hat 10.1.1-1) on fedora 32. With either 3.15.0 or current
valgrind git.

But when building with LTO it looks like the (relative) paths to the VEX
library linked into memcheck-amd64-linux doesn't come out correctly. Both
valgrind and gdb cannot find the actual files, even when in the build dir.

You can see the same issue with elfutils eu-readelf --debug-dump=decodedline
./install/lib/valgrind/memcheck-amd64-linux

Without lto you'll get full (absolute) path names:

 CU [b] mc_leakcheck.c
  line:col SBPE* disc isa op address (Statement Block Prologue Epilogue *End)
  /tmp/valgrind-3.15.0/memcheck/mc_leakcheck.c (mtime: 0, length: 0)
   253:1   S        0   0  0 0x0000000058001070 <compare_MC_Chunks>
   254:4   S        0   0  0 0x0000000058001070 <compare_MC_Chunks>
   255:4   S        0   0  0 0x0000000058001070 <compare_MC_Chunks>
   256:4   S        0   0  0 0x0000000058001070 <compare_MC_Chunks>
   256:11           0   0  0 0x0000000058001070 <compare_MC_Chunks>
   256:23           0   0  0 0x0000000058001073 <compare_MC_Chunks+0x3>
   256:7            0   0  0 0x0000000058001076 <compare_MC_Chunks+0x6>
   257:7            0   0  0 0x000000005800107e <compare_MC_Chunks+0xe>
   259:1            0   0  0 0x000000005800108c <compare_MC_Chunks+0x1c>

While with lto some of the paths seem relative (but to what?):

 CU [b] <artificial>
  line:col SBPE* disc isa op address (Statement Block Prologue Epilogue *End)
  priv/guest_amd64_toIR.c (mtime: 0, length: 0)
  2036:0            0   0  0 0x0000000058001000 <sameIRExprs_aux2.cold>
  2446:0            0   0  0 0x0000000058001007 <show_hwcaps.cold>
  /home/mark/valgrind/memcheck/m_mallocfree.c (mtime: 0, length: 0)
  2643:0            0   0  0 0x000000005800100e <umsg_arg.cold>
  /home/mark/valgrind/memcheck/m_libcprint.c (mtime: 0, length: 0)
    61:0   S        0   0  0 0x000000005800100e <umsg_arg.cold>
    61:0   S        0   0  0 0x000000005800100e <umsg_arg.cold>
    61:0   S        0   0  0 0x000000005800100e <umsg_arg.cold>
  /home/mark/valgrind/memcheck/m_mallocfree.c (mtime: 0, length: 0)
  2643:0            0   0  0 0x0000000058001018 <xml_arg.cold>
  /home/mark/valgrind/memcheck/m_libcprint.c (mtime: 0, length: 0)
    61:0   S        0   0  0 0x0000000058001018 <xml_arg.cold>
    61:0   S        0   0  0 0x0000000058001018 <xml_arg.cold>
    61:0   S        0   0  0 0x0000000058001018 <xml_arg.cold>
    61:0   S   *    0   0  0 0x0000000058001021 <xml_arg.cold+0x9>

  priv/guest_amd64_toIR.c (mtime: 0, length: 0)
  7007:0   S        0   0  0 0x0000000058001150 <compare_MC_Chunks>
  7011:0   S        0   0  0 0x0000000058001150 <compare_MC_Chunks>
  7012:0   S        0   0  0 0x0000000058001150 <compare_MC_Chunks>
  7013:0   S        0   0  0 0x0000000058001150 <compare_MC_Chunks>
  7014:0            0   0  0 0x000000005800115e <compare_MC_Chunks+0xe>
  7010:0            0   0  0 0x000000005800116c <compare_MC_Chunks+0x1c>

This looks similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
(".debug_line with LTO refers to bogus file-names")