From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0C7623858406; Thu, 3 Mar 2022 02:28:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C7623858406 From: "simark at simark dot ca" To: gdb-prs@sourceware.org Subject: [Bug c++/28935] GDB very slow stepping through LLVM compiled by Clang Date: Thu, 03 Mar 2022 02:28:58 +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: simark at simark dot ca 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: Thu, 03 Mar 2022 02:28:59 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28935 --- Comment #3 from Simon Marchi --- (In reply to Martin Sebor from comment #2) > In both of my sessions GDB stops on the same lines and shows the same out= put > (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 thoug= ht. > 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). >=20 > If you're willing to try to reproduce it with LLVM (and ideally with Emac= s) > that would be great. >=20 > I use stock GCC and LLVM (and Emacs) on Fedora 35 to build LLVM: >=20 > gcc version 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC) > clang version 13.0.0 (Fedora 13.0.0-3.fc35) >=20 > I invoke CMake to configure LLVM for Clang and Ninja either in > /build/llvm-clang or /build/llvm-gcc, respectively, like so: >=20 > $ CC=3Dclang CXX=3Dclang++ cmake -G Ninja /src/llvm/llvm -DLLVM_USE_LIN= KER=3Dlld > -DLLVM_ENABLE_PROJECTS=3D"llvm" >=20 > (or without CC and CXX to use the stock GCC), and the use Ninja to build: >=20 > $ ninja -C /build/llvm-clang -j16 -l12 -v > or > $ ninja -C /build/llvm-gcc -j16 -l12 -v >=20 > While LLVM is building, create an a.ll file from the C program shown belo= w: >=20 > $ 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 executa= ble > with the options as shown and the a.ll file as an operand: >=20 > $ 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(); } >=20 > (Your line numbers will be different than mine.) The step command and ot= her > 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 abo= ut > 3 seconds when I start the same GDB session in Emacs (or in VSCode). Whe= n I > follow the same steps with LLVM compiled with GCC the step and next comma= nds > 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 > and next complete without a delay either way. Ok, I tried to follow this as best as I could, but I can't see a noticeable difference between both, unfortunately. I tested on Ubuntu 20.04 (but also= gcc 11, from the Ubuntu toolchain PPA, and clang 13, from the LLVM apt repo). I didn't test with emacs, as I have no idea how to use it. --=20 You are receiving this mail because: You are on the CC list for the bug.=