[llvm-bugs] [Bug 43530] New: Single-stepping through clang-cl code randomly drops into assembly language

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Oct 1 13:20:44 PDT 2019


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

            Bug ID: 43530
           Summary: Single-stepping through clang-cl code randomly drops
                    into assembly language
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: brucedawson at chromium.org
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

While debugging either compiler_proxy.exe or chrome.exe I have noticed that
sometimes single-stepping through plain C++ code will suddenly drop me into the
disassembly window. The exact details depend on user settings and whether you
are debugging a locally built binary or one from the build machines. Some
people have auto-switch to disassembly disabled so they just see a warning page
saying:

    cpu.cc not found

    You need to find cpu.cc to view the source for the current call stack frame

Viewing details gives me this:

    Locating source for 'c:\src\chromium3\src\base\cpu.cc'. Checksum: MD5 {f2
8b 7a f0 cb f 9d f3 29 47 b3 b6 9c c0 2b 33}
    The file 'c:\src\chromium3\src\base\cpu.cc' exists.
    Determining whether the checksum matches for the following locations:
    1: c:\src\chromium3\src\base\cpu.cc Checksum: MD5 {f2 8b 7a f0 cb f 9d f3
29 47 b3 b6 9c c0 2b 33} Checksum matches.
    The debugger found source in the following locations:
    1: c:\src\chromium3\src\base\cpu.cc Checksum: MD5 {f2 8b 7a f0 cb f 9d f3
29 47 b3 b6 9c c0 2b 33}
    The debugger will use the source at location 1.

There is a Browse and find cpu.cc link but it doesn't work.

It is odd that the debugger says that the source matches and that it will use
it but then it doesn't. It *might* be a debugger bug but it seems suspicious
that the debugger happily steps through code and then switches to assembly
language. It feels like there is a discontinunity in the source mappings. When
debugging VC++-generated code I have not seen this behavior.

If I use Ctrl+O to load the specified file it loads but doesn't show any
"execution is here" cursor. If I use Ctrl+F11 to switch to assembly mode it
asks me to disambiguate and then takes me here (the cmp instruction):

  static_assert(kParameterSize * sizeof(cpu_info) + 1 ==
base::size(cpu_string),
                "cpu_string has wrong size");

  if (max_parameter >= kParameterEnd) {
001A3C49 3D 04 00 00 80       cmp         eax,80000004h  
001A3C4E 7C 68                jl          base::CPU::Initialize+238h (01A3CB8h) 
// Copyright (c) 2012 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.


Again, no cursor showing that execution is there. Right-clicking and selecting
Show Next Statement takes me here - on the first mov instruction:

  return PENTIUM;
}

}  // namespace base

001A3C50 89 C7                mov         edi,eax  
    size_t i = 0;
    for (int parameter = kParameterStart; parameter <= kParameterEnd;
         ++parameter) {
      __cpuid(cpu_info, parameter);
001A3C52 B8 02 00 00 80       mov         eax,80000002h  


If I single-step to the next instruction then Ctrl+F11 works and I can go back
to source code with an execution cursor and all is well.

So, it looks like there is a source-to-assembly discontinuity on the
instruction at address 001A3C50.

The easiest way to reproduce this is to set a breakpoint on line 255 of
base\cpu.cc then single step (F10). That's it.

I reproduced this at Chromium hash 8a9aaaa8c338d22a97442e87518f23a661bef002. I
don't know how stable this exact repro is. Here are the gn args I used:

is_component_build = false
is_debug = false
target_cpu = "x86"
enable_nacl = false
dcheck_always_on = true
use_goma = true
blink_symbol_level = 1

-- 
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/20191001/3578ba98/attachment.html>


More information about the llvm-bugs mailing list