[llvm-bugs] [Bug 40319] New: [DebugInfo] X86DiscriminateMemOps inserts potentially misleading line numbers

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=40319

            Bug ID: 40319
           Summary: [DebugInfo] X86DiscriminateMemOps inserts potentially
                    misleading line numbers
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: jeremy.morse.llvm at gmail.com
                CC: craig.topper at gmail.com, davidxl at google.com,
                    douglas_yung at playstation.sony.com,
                    greg.bedwell at sony.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, mtrofin at google.com,
                    spatel+llvm at rotateright.com, wmi at google.com

Hi, if one compiles the following sample with llvm/clang r351192 and the
command line "clang -x c++ test.cpp -fdebug-info-for-profiling 
-fstack-protector -o a.out -O0 -g -c",

--------8<--------
int foo (int input_param)
{
    int array1[input_param];
    array1[0]=18;

    return array1[0];
}
-------->8--------

And then examine the line tables with dwarfdump -l a.out:

--------8<--------
0x00000000  [   2, 0] NS uri: "/home/jmorse/fdebug.cpp"
0x00000011  [   1, 0] NS PE DI=0x2
0x00000015  [   1, 0] DI=0x4
0x00000018  [   3,16] NS
0x0000001d  [   3, 5]
0x00000020  [   3, 5] DI=0x2
0x00000024  [   3, 5] DI=0x4
...
-------->8--------

We have the line numbers going backwards at the start of the function (two to
one to three). This is due to the x86-discriminate-memops pass picking the
default line number to instrument memory operations with as being the start of
the function. (See ReferenceDI in X86DiscriminateMemOps.cpp).

These line numbers are potentially misleading IMHO -- would we be able to use a
zero line number by default instead? According to the DWARF spec this
corresponds to compiler-generated code and will be ignored by debuggers. That
way X86DiscriminateMemOps won't have any affect on debugging, and the change
(AFAIK) will have no effect on its operation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190115/67a44cbc/attachment.html>