New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 4 users

Issue metadata

Status: Verified
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on:
issue 764744

Blocking:
issue 636111
issue 709690



Sign in to add a comment

(debug build) "Step into specific" menu item not working in MSVS

Project Member Reported by jam@chromium.org, Aug 16 2017

Issue description

The step into specific menu item is very useful, i.e. look at the NavigationURLLoader::Create call in NavigationRequest. Once my debugger is at that line, if I specify it to step into NavigationURLLoader::Create it doesn't work.

This is the same gn args as in  bug 755213 .
 

Comment 1 by jam@chromium.org, Aug 16 2017

Blocking: 636111
I can repro it in Chrome, trying to make a minimal repro.
Cc: r...@chromium.org
Owner: zturner@chromium.org
Status: Assigned (was: Untriaged)
Here's a minimal repro.  This should be pretty easy to track down.

// step.cpp
// clang-cl.exe -m32 /Od /Z7 /MDd /GR- /c step.cpp /Fostep.obj
// link /debug step.obj /out:step.exe
#include <type_traits>
struct Foo {
  Foo() {}
  Foo(Foo &&Other) {}
};

void Bar(Foo F) { }

int main(int argc, char **argv) {
  Foo F;

  // The following line works, step into specific "Bar" goes into Bar
  Bar(std::move(F));

  // The following line fails, step into specific "Bar" moves to the line
  // with the std::move(F)
  Bar(
    std::move(F));

  return argc;
}

Here's the line info we're generating vs. the line info that cl is generating:

// cl's line info
> llvm-pdbutil dump -l step-cl.pdb
  Mod 0000 | `D:\test\step-cl.obj`:
      d:\test\step.cpp (MD5: 24490228E3FB059697794935EF684793)
        0001:00000040-00000045, line/addr entries = 1
           7 00000040

        0001:00000050-00000084, line/addr entries = 5
           9 00000050     10 00000055     11 0000005D     14 0000007C     15 0000007F

      d:\test\step.cpp (MD5: 24490228E3FB059697794935EF684793)
        0001:000000B0-000000C0, line/addr entries = 1
           4 000000B0

        0001:000000D0-000000DE, line/addr entries = 1
           3 000000D0

and here's the mixed assembly/source view.

; 9 - int main(int argc, char **argv) {
  40104c:       cc      int3
  40104d:       cc      int3
  40104e:       cc      int3
  40104f:       cc      int3
  401050:       55      push    ebp
  401051:       8b ec   mov     ebp, esp
  401053:       51      push    ecx
  401054:       56      push    esi
; 10 - Foo F;
  401055:       8d 4d ff        lea     ecx, [ebp - 1]
  401058:       e8 a8 ff ff ff  call    -88 <.text+0x5>
; 11 - Bar(
  40105d:       51              push    ecx
  40105e:       8b f4           mov     esi, esp
  401060:       8d 45 ff        lea     eax, [ebp - 1]
  401063:       50              push    eax
  401064:       e8 ab ff ff ff  call    -85 <.text+0x14>
  401069:       83 c4 04        add     esp, 4
  40106c:       50              push    eax
  40106d:       8b ce           mov     ecx, esi
  40106f:       e8 9b ff ff ff  call    -101 <.text+0xF>
  401074:       e8 91 ff ff ff  call    -111 <.text+0xA>
  401079:       83 c4 04        add     esp, 4
; 14 - return argc;
  40107c:       8b 45 08        mov     eax, dword ptr [ebp + 8]
; 15 - }


// ou4 line info
D:\test>d:\src\llvmbuild\ninja\bin\llvm-pdbutil dump -l step.pdb
  Mod 0000 | `D:\test\step.obj`:
      D:\test\step.cpp (no checksum)
        0001:00000040-0000004F, line/addr entries = 1
           7 00000040 !

        0001:00000050-000000BA, line/addr entries = 6
           9 00000050 !   10 0000006A !   11 0000007A !   12 0000007F !   11 000000A1 !   14 000000B1 !

        0001:000000E0-000000EF, line/addr entries = 1
           3 000000E0 !

      D:\test\step.cpp (no checksum)
        0001:00000120-0000013B, line/addr entries = 1
           4 00000120 !

and mixed source/assembly:

; 9 - int main(int argc, char **argv) {
  40104f:       90                      nop
  401050:       55                      push    ebp
  401051:       89 e5                   mov     ebp, esp
  401053:       56                      push    esi
  401054:       83 ec 24                sub     esp, 36
  401057:       8b 45 0c                mov     eax, dword ptr [ebp + 12]
  40105a:       8b 4d 08                mov     ecx, dword ptr [ebp + 8]
  40105d:       8d 55 f4                lea     edx, [ebp - 12]
  401060:       c7 45 f8 00 00 00 00    mov     dword ptr [ebp - 8], 0
  401067:       8d 75 f4                lea     esi, [ebp - 12]
; 10 - Foo F;
  40106a:       89 4d f0                mov     dword ptr [ebp - 16], ecx
  40106d:       89 f1                   mov     ecx, esi
  40106f:       89 45 ec                mov     dword ptr [ebp - 20], eax
  401072:       89 55 e8                mov     dword ptr [ebp - 24], edx
  401075:       e8 8b ff ff ff          call    -117 <.text+0x5>
; 11 - Bar(
  40107a:       89 e1                   mov     ecx, esp
  40107c:       50                      push    eax
  40107d:       89 e2                   mov     edx, esp
; 12 - std::move(F));
  40107f:       83 ec 04                sub     esp, 4
  401082:       8b 75 e8                mov     esi, dword ptr [ebp - 24]
  401085:       89 34 24                mov     dword ptr [esp], esi
  401088:       89 45 e4                mov     dword ptr [ebp - 28], eax
  40108b:       89 4d e0                mov     dword ptr [ebp - 32], ecx
  40108e:       89 55 dc                mov     dword ptr [ebp - 36], edx
  401091:       e8 7e ff ff ff          call    -130 <.text+0x14>
  401096:       8b 4d dc                mov     ecx, dword ptr [ebp - 36]
  401099:       89 04 24                mov     dword ptr [esp], eax
  40109c:       e8 6e ff ff ff          call    -146 <.text+0xF>
; 11 - Bar(
  4010a1:       89 45 d8                mov     dword ptr [ebp - 40], eax
  4010a4:       e8 61 ff ff ff          call    -159 <.text+0xA>
  4010a9:       83 c4 04                add     esp, 4
  4010ac:       8b 45 e0                mov     eax, dword ptr [ebp - 32]
  4010af:       89 c4   mov             esp, eax
; 14 - return argc;
  4010b1:       8b 45 08                mov     eax, dword ptr [ebp + 8]
  4010b4:       8d 65 fc                lea     esp, [ebp - 4]
  4010b7:       5e                      pop     esi
  4010b8:       5d                      pop     ebp
  4010b9:       c3                      ret

So, I think this explains what we're seeing.  I'm guessing that this Step Into Specific is only really tested against their generated code, so the fact that we're re-ordering some code confuses their algorithm.  Will have to think about how to fix it.

Comment 5 by r...@chromium.org, Aug 16 2017

We found another stepping difference. If you step through main mashing F10, with clang it will step backwards as it evaluates each argument right to left (to match MSVC, no less!), until it gets to the outer statement. With MSVC, it treats it as a single line. For example, I can't break on line 8 in this example with MSVC, but with clang, it'll work and stop on the second call to x().

int g(int a, int b, int c, int d, int e, int f) {
  return a + b + c + d + e + f;
}
int x() { return 1; }
int main() {
  return g(
      x(),
      x(),
      x(),
      x(),
      x(),
      x()
      );
}

Changing that would be a matter of conditionalizing all the ApplyDebugInfo calls in clang/lib/CodeGen/CGExpr.cpp.
I hex edited my PDB (can't even believe I'm saying this, lol) to get rid of the line information of the intermediate statements.  After hex editing, line info looks like this:

                           Lines
============================================================
  Mod 0000 | `D:\test\step.obj`:
      D:\test\step.cpp (no checksum)
        0001:00000040-0000004F, line/addr entries = 1
           7 00000040 !

        0001:00000050-000000BA, line/addr entries = 6
           9 00000050 !   10 0000006A !   11 0000007A !   14 000000B1 !   14 000000B1 !   14 000000B1 !

Whereas before it went 11 -> 12 -> 11 -> 14, now it goes 11 -> 14.  With this change, Step Into Specific works as expected, so I think we can conclude that the bug is that MS debugger doesn't work well in the presence of split line info for multi-line statements.  Ugh.
Cc: inglorion@chromium.org h...@chromium.org amccarth@chromium.org
Components: Build
Owner: ----
Status: Available (was: Assigned)
+other people who might be interested.

Comment 8 by r...@chromium.org, Aug 23 2017

Blocking: 709690

Comment 9 by r...@chromium.org, Aug 24 2017

Eric said he was interested this, so I filed an upstream bug with info on what needs doing and how to get started: https://bugs.llvm.org/show_bug.cgi?id=34312
 Issue 759105  has been merged into this issue.

Comment 11 by dxf@google.com, Sep 7 2017

Owner: inglorion@chromium.org

Comment 12 by h...@chromium.org, Sep 13 2017

Bob, Reid: was this one fixed, or what's the status?

Comment 13 by r...@chromium.org, Sep 13 2017

Landed in r312965, so it's in the roll.

Comment 14 by h...@chromium.org, Sep 13 2017

Blockedon: 764744
Excellent.

Comment 15 by h...@chromium.org, Oct 5 2017

Bob, since we've rolled past r312965, should this be closed as fixed?
Status: Verified (was: Available)
Just verified. This works now.

Comment 17 by jam@chromium.org, Oct 20 2017

Thanks, I've verified this.

Sign in to add a comment