From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 97DFB3858D39; Wed, 2 Mar 2022 18:25:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 97DFB3858D39 From: "msebor at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug c++/28935] New: GDB very slow stepping through LLVM compiled by Clang Date: Wed, 02 Mar 2022 18:25:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: c++ X-Bugzilla-Version: 11.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2022 18:25:20 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28935 Bug ID: 28935 Summary: GDB very slow stepping through LLVM compiled by Clang Product: gdb Version: 11.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ Assignee: unassigned at sourceware dot org Reporter: msebor at gmail dot com Target Milestone: --- Stepping through C++ code compiled by Clang takes much longer than when the code is compiled by GCC. For example, when debugging LLVM, each step takes= a second or more. This is with the stock GDB (11.1-5.fc35) on x86_64 running Fedora 35. That makes using GDB for interactive work impractical. Using G= CC instead of Clang to compile LLVM is a viable workaround but it's not without issues of its own. LLDB doesn't have the same problem as GDB but because i= t's not fully compatible with GDB it's not a great solution for those of us use= d to GDB. I'd like to try to help isolate and fix this problem. Below is a test case independent of LLVM that shows a small but measurable difference between th= ese two scenarios. The output is the number of microseconds it takes the three 'next' GDB commands to step over the three C++ statements in A::f(), averag= ed over 100 runs. In GCC-compiled code the average is 5.2 microseconds, in Clang-compiled code it's 5.5 microseconds. If the difference grows with co= de size and/or complexity it could explain the much bigger 1 second delay in L= LVM. If this test case isn't representative of the problem can you suggest what might be? $ (cat t.C && g++ -ggdb -o a.gcc.out t.C && (n=3D0; while [ $n -lt 100 ]; d= o gdb -batch -nx -ex "break A::f" -ex run -ex next -ex next -ex next -ex continue ./a.gcc.out >/dev/null; n=3D$((n+1)); done) 2>&1 | awk 'BEGIN { t =3D 0.0 }= { t +=3D $1 } END { print t / 100 }' ) #include #include #include struct A { void f () const { std::string s =3D "Hello, "; s +=3D "World!"; std::cout << s << std::endl; } }; A a; int main () { struct timespec t0, t1; clock_gettime (CLOCK_MONOTONIC, &t0); a.f (); clock_gettime (CLOCK_MONOTONIC, &t1); double t =3D (t1.tv_sec - t0.tv_sec) * 1e3 + (t1.tv_nsec - t0.tv_nsec) / = 1e3;=20 fprintf (stderr, "%f ms\n", t / 1e3); } 5.19838 $ (clang++ -ggdb -o a.clang.out t.C && (n=3D0; while [ $n -lt 100 ]; do gdb -batch -nx -ex "break A::f" -ex run -ex next -ex next -ex next -ex continue ./a.clang.out >/dev/null; n=3D$((n+1)); done) 2>&1 | awk 'BEGIN { n =3D 0.0= } { n +=3D $1 } END { print n / 100 }' ) 5.52529 --=20 You are receiving this mail because: You are on the CC list for the bug.=