From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F13373858407; Wed, 2 Mar 2022 22:41:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F13373858407 From: "msebor at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug c++/28935] GDB very slow stepping through LLVM compiled by Clang Date: Wed, 02 Mar 2022 22:41:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed 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: Message-ID: In-Reply-To: References: 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 22:41:32 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28935 --- Comment #2 from Martin Sebor --- In both of my sessions GDB stops on the same lines and shows the same outpu= t (I pasted the output below just in case I'm overlooking something). But with = more testing I think the problem might be more involved than I thought. I reproduces in GDB in Emacs (and also in VSCode) but it's not nearly as pronounced with GDB invoked in the terminal (there's a still a delay there = but much shorter). If you're willing to try to reproduce it with LLVM (and ideally with Emacs) that would be great. I use stock GCC and LLVM (and Emacs) on Fedora 35 to build LLVM: gcc version 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC) clang version 13.0.0 (Fedora 13.0.0-3.fc35) I invoke CMake to configure LLVM for Clang and Ninja either in /build/llvm-clang or /build/llvm-gcc, respectively, like so: $ CC=3Dclang CXX=3Dclang++ cmake -G Ninja /src/llvm/llvm -DLLVM_USE_LINKE= R=3Dlld -DLLVM_ENABLE_PROJECTS=3D"llvm" (or without CC and CXX to use the stock GCC), and the use Ninja to build: $ ninja -C /build/llvm-clang -j16 -l12 -v or $ ninja -C /build/llvm-gcc -j16 -l12 -v While LLVM is building, create an a.ll file from the C program shown below: $ cat a.c && clang -O1 -S -emit-llvm -Xclang -disable-llvm-passes -o a.ll= a.c void f (void *p, void *q) { __builtin_memcpy (p, q, 4); } Once LLVM is finished building, start a GDB session (either on the command line, or better, in Emacs, with M-x gdb) with opt as the executable, set a breakpoint in llvm::MemCpyOptPass::processMemCpy, and run the opt executable with the options as shown and the a.ll file as an operand: $ gdb -nx /build/llvm-clang/bin/opt (gdb) break llvm::MemCpyOptPass::processMemCpy (gdb) run -S -basic-aa -memcpyopt a.ll Breakpoint 1, llvm::MemCpyOptPass::processMemCpy (this=3D0x994ba28, M=3D0x994c2c0, BBI=3D...) at /src/llvm/llvm/lib/Transforms/Scalar/MemCpyOptimizer.cpp:1375 1375 if (M->isVolatile()) return false; (gdb) step llvm::MemIntrinsic::isVolatile (this=3D0x994c2c0) at /src/llvm/llvm/include/llvm/IR/IntrinsicInst.h:953 953 bool isVolatile() const { return !getVolatileCst()->isZero(); } (Your line numbers will be different than mine.) The step command and other next or step commands in this context take about a second to complete in GDB started in a terminal. That's long but actually tolerable. It takes about= 3 seconds when I start the same GDB session in Emacs (or in VSCode). When I follow the same steps with LLVM compiled with GCC the step and next commands complete pretty much instantaneously, both in GDB started in a terminal or (with a slight delay) in Emacs. In other contexts (like in main()), step a= nd next complete without a delay either way. So there must be something about the Emacs GDB IDE mode that causes this multi-second delay. Sorry I didn't mention it to begin with. I just notic= ed it as I was preparing this reply. $ (g++ -ggdb -o a.gcc.out t.C && (n=3D0; while [ $n -lt 1 ]; do gdb -batch = -nx -ex "break A::f" -ex run -ex next -ex next -ex next -ex continue ./a.gcc.ou= t; n=3D$((n+1)); done)) Breakpoint 1 at 0x402439: file t.C, line 9. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, A::f (this=3D0x405269 ) at t.C:9 9 std::string s =3D "Hello, "; 10 s +=3D "World!"; 11 std::cout << s << std::endl; Hello, World! 12 } 5.195867 ms [Inferior 1 (process 279003) exited normally] $ (clang++ -ggdb -o a.clang.out t.C && (n=3D0; while [ $n -lt 1 ]; do gdb -= batch -nx -ex "break A::f" -ex run -ex next -ex next -ex next -ex continue ./a.clang.out; n=3D$((n+1)); done)) Breakpoint 1 at 0x401314: file t.C, line 9. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, A::f (this=3D0x4041ea ) at t.C:9 9 std::string s =3D "Hello, "; 10 s +=3D "World!"; 11 std::cout << s << std::endl; Hello, World! 12 } 5.536339 ms [Inferior 1 (process 279049) exited normally] --=20 You are receiving this mail because: You are on the CC list for the bug.=