[llvm-bugs] [Bug 37462] New: Global function not visible to VS debugger

[via llvm-bugs]

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

            Bug ID: 37462
           Summary: Global function not visible to VS debugger
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: COFF
          Assignee: unassignedbugs at nondot.org
          Reporter: alexandre.ganea at ubisoft.com
                CC: llvm-bugs at lists.llvm.org

We are using global functions to be called at runtime, to debug certain complex
structures. These functions are linked in the .exe, but not used by other
functions in the .exe; they are only meant to be called while debugging in
Immediate Mode (in Visual Studio - using 2017 15.7.1).

We ensure the functions are forced linked in the .exe, with the following:

      void DebugStructure( unsigned __int64 value ) { ... }

      bool ms_LinkTrick = false;
      void DebugInit() {
        if ( ms_LinkTrick ) {
          ::DebugStructure( 0ull );
        }
      }

      int main() {
        DebugInit();
      }


When using link.exe the function is there and can be called in the debugger.

      &DebugStructure   0x00000001408c2040
{myexe_vs2017.exe!DebugStructure(unsigned __int64)}  void(*)(unsigned __int64)

However when using lld-link.exe, the function can only be randomly reached.
Randomly, as is in, if I put a breakpoint in DebugInit(), the function can be
used. However if I don't, and break later on, the function will not be shown.

      &myexe_vs2017.exe!DebugStructure      identifier "DebugStructure" is
undefined    

If I find its adress and I go in the disassembly, I can see it there, but the
debugger doesn't find it.

I have not be able to reproduce the issue in a test-case.

The symbol is there in the .pdb as expected. The only difference I could spot
is the layout in the symbol stream:

MSVC generates this:

(009200) S_GPROC32: [0001:008C1020], Cb: 00000018, Type:             0x761F,
DebugStructure
         Parent: 00000000, End: 00009264, Next: 00000000
         Debug start: 00000009, Debug end: 00000013

(009230)  S_FRAMEPROC:
          Frame size = 0x00000028 bytes
          Pad size = 0x00000000 bytes
          Offset of pad in frame = 0x00000000
          Size of callee save registers = 0x00000000
          Address of exception handler = 0000:00000000
          Function info: asynceh invalid_pgo_counts opt_for_speed Local=rsp
Param=rsp (0x00114200)
(009250)  S_REGREL32: rsp+00000030, Type:      T_UQUAD(0023), value

(009264) S_END

...while LLD generates this:

(0477B0) S_GPROC32: [0001:00B6A280], Cb: 00000019, Type:             0x79E4,
DebugStructure
         Parent: 00000000, End: 00047804, Next: 00000000
         Debug start: 00000000, Debug end: 00000000

(0477E0)  S_LOCAL: Param: 00000023, value
(0477F0)  S_DEFRANGE_REGISTER_REL: [rsp +  0020 ]
        Range: [0001:00B6A289] - [0001:00B6A299], 0 Gaps

(047804) S_END


The LLD result seem to come from this: CodeViewDebug::emitLocalVariable()

I was wondering if the S_FRAMEPROC isn't needed after all? Any ideas?

-- 
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/20180514/4f5ec785/attachment.html>