From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 438163858D37; Thu, 9 Nov 2023 12:47:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 438163858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1699534028; bh=LpWMb6qPCi1QzzpsFolAqZWaNGuXVqiRZn9ZBRLoOlw=; h=From:To:Subject:Date:From; b=aIh1agCs6elyk3ZBuyO8PGGVZJ02x/gwXK09BHP50IWAeo9+bQNYOwDjO4NJyyWpg 8O0KwTq2/fFO9sITxorWmoXG1VhfpC8e5j/gKXyTyEHEKmXRWtmtOxkPxcXVu4NVwG xYXODsWn1JfUz+t7kitkZKWzH0oL5aNhrk4RNbBI= From: "aditya24.garg at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/31048] New: GDB commands very slow due to too many lseek calls Date: Thu, 09 Nov 2023 12:47:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 9.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: aditya24.garg 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 cc 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 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31048 Bug ID: 31048 Summary: GDB commands very slow due to too many lseek calls Product: gdb Version: 9.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: aditya24.garg at gmail dot com CC: aditya24.garg at gmail dot com Target Milestone: --- OS: Linux (Ubuntu 20.04.5) Overview: I have a project consisting of multiple .so files. I have refacto= red one of the .so files to a templatized version, therefore now i have quite a= few template classes and functions. Now on using GDB for debugging, commands li= ke print/ptype are running extremely slow in certain frames. Its taking over a minute to just execute ptype Actual Results: For local args and variables, GDB print/ptype works pretty = fast but with one of the static singleton variables, GDB print/ptype is taking 1 minute to execute. I tried using strace on gdb PID and saw that over 5000 L= SEEK calls for the same offset were being made repeatedly. >From comment on another old ticket (https://sourceware.org/bugzilla/show_bug.cgi?id=3D17764#c5), I tried setti= ng demangle-style to none after which this problem disappeared. Everything bec= ame superfast. But debugging with mangled names is very inconvenient so i am exploring solutions to fix this slowness while still using demangler. Expected Results: Expectation was that GDB will return response within a few seconds, instead its taking around a minute. GDB Version: GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2 Environment:=20 OS: Linux 5.4.0-135-generic #152-Ubuntu SMP Wed Nov 23 20:19:22 UTC 2022 x8= 6_64 x86_64 x86_64 GNU/Linux GCC: Using built-in specs. COLLECT_GCC=3Dgcc COLLECT_LTO_WRAPPER=3D/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper OFFLOAD_TARGET_NAMES=3Dnvptx-none:hsa OFFLOAD_TARGET_DEFAULT=3D1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion=3D'Ubuntu 9.4.0-1ubuntu1~20.04.1' --with-bugurl=3Dfile:///usr/share/doc/gcc-9/README.= Bugs --enable-languages=3Dc,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix= =3D/usr --with-gcc-major-version-only --program-suffix=3D-9 --program-prefix=3Dx86_64-linux-gnu- --enable-shared --enable-linker-build-= id --libexecdir=3D/usr/lib --without-included-gettext --enable-threads=3Dposix --libdir=3D/usr/lib --enable-nls --enable-clocale=3Dgnu --enable-libstdcxx-= debug --enable-libstdcxx-time=3Dyes --with-default-libstdcxx-abi=3Dnew --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=3Dauto --enable-objc-gc=3Dauto --enable-multiarch --disable-werror --with-arch-32= =3Di686 --with-abi=3Dm64 --with-multilib-list=3Dm32,m64,mx32 --enable-multilib --with-tune=3Dgeneric --enable-offload-targets=3Dnvptx-none=3D/build/gcc-9-Av3uEd/gcc-9-9.4.0/deb= ian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=3Drelease --build=3Dx86_64-linux-gnu --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux-gnu Thread model: posix gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) GDB: This GDB was configured as "x86_64-linux-gnu" Strace Logs: lseek(158, 4980736, SEEK_SET) =3D 4980736 lseek(158, 4980736, SEEK_SET) =3D 4980736 lseek(158, 4980736, SEEK_SET) =3D 4980736 lseek(158, 4980736, SEEK_SET) =3D 4980736 lseek(158, 4980736, SEEK_SET) =3D 4980736 lseek(158, 4980736, SEEK_SET) =3D 4980736 lseek(158, 4980736, SEEK_SET) =3D 4980736 lseek(158, 4980736, SEEK_SET) =3D 4980736 ptrace(PTRACE_PEEKTEXT, 865894, 0x7fffe0ccb260, [0x7fffe3a0c920]) =3D 0 rt_sigaction(SIGINT, {sa_handler=3D0x556e929a32e0, sa_mask=3D[INT], sa_flags=3DSA_RESTORER|SA_RESTART, sa_restorer=3D0x7fb93304d090}, {sa_handler=3D0x556e929a32e0, sa_mask=3D[INT], sa_flags=3DSA_RESTORER|SA_RE= START, s> brk(0x556ec2ea5000) =3D 0x556ec2ea5000 brk(0x556ec2ec6000) =3D 0x556ec2ec6000 brk(0x556ec2ee7000) =3D 0x556ec2ee7000 brk(0x556ec2f08000) =3D 0x556ec2f08000 brk(0x556ec2f29000) =3D 0x556ec2f29000 brk(0x556ec2f4a000) =3D 0x556ec2f4a000 Interesting fact: When i execute ptype . It takes 1 minute to run when current frame selected (lets say frame 5) is from file1.so. And if i g= o to frame 10 which belongs to file2.so, then same ptype command executes in 5 seconds. All the changes i have made are for file2.so and no change has been made to file1.so implementation. --=20 You are receiving this mail because: You are on the CC list for the bug.=