Re: [EXT] Re: Slow "symbol-file" when using GDB 12.1 on Windows hosts
Luis Machado via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
On 4/4/23 15:07, Adrian Oltean wrote: >> -----Original Message----- >> From: Luis Machado <[email protected]> >> Sent: Tuesday, April 4, 2023 4:02 PM >> To: Adrian Oltean <[email protected]>; Eli Zaretskii <[email protected]> >> Cc: [email protected] >> Subject: Re: [EXT] Re: Slow "symbol-file" when using GDB 12.1 on Windows >> hosts >> >> Caution: EXT Email >> >> On 4/3/23 17:48, Adrian Oltean wrote: >>>> -----Original Message----- >>>> From: Luis Machado <[email protected]> >>>> Sent: Wednesday, March 22, 2023 4:31 PM >>>> To: Eli Zaretskii <[email protected]>; Adrian Oltean >>>> <[email protected]> >>>> Cc: [email protected] >>>> Subject: Re: [EXT] Re: Slow "symbol-file" when using GDB 12.1 on >>>> Windows hosts >>>> >>>> >>>> The logic to lookup debug info is OS-invariant I think, but gdb does >>>> have to adjust to the Windows-style paths. >>>> >>>> With that said, most of the attempts gdb does at accessing >>>> directories is an attempt to locate separate debug info files or >>>> simply to locate shared library symbol files. >>>> >>>> Since there is quite a bit of variation in terms of where an OS puts >>>> those files, gdb has to use heuristics to try to determine those >>>> directories, so it will try to access gdb-generated paths sometimes. >>>> >>>> It shouldn't slow things down though, as it is mostly a file open/close request. >>> >>> Hi guys, >>> >>> I managed to identify what's causing the described behavior. The CSC >>> folder is actually accessed indirectly because of the fact that a >>> network share is attempted to be accessed by GDB on Windows - see paths >> like " \\lib\debug" in my previous emails. >>> >>> The fact that GDB is trying to access (most likely invalid in almost >>> all setups) network shares like " \\lib\debug" on Windows hosts, I'm >>> pretty sure the slowdown isn't happening only for me (actually, all >>> PCs from our organization). Note that this path is the one specific to latest >> GDB 12 build delivered by ARM: >>> (gdb) show debug-file-directory >>> The directory where separate debug symbols are searched for is "\\lib\debug". >>> >>> For GDB 10 I see: >>> (gdb) show debug-file-directory >>> The directory where separate debug symbols are searched for is >> "c:\mnt\workspace\workspace\gcc-10-pipeline\jenkins-gcc-10-pipeline- >> 338_20211018_1634516203\install-mingw\lib\debug". >>> >>> As far as I can tell, ARM changed something in their build environment >>> causing this unwanted effect. With this findings, I decided to >>> workaround the problem by setting debug-file-directory to an empty value >> once GDB starts-up. >> >> The default debug-file-directory gets set during configure/build. I don't think the >> previous path is correct, as it is obviously a path internal to the build machine. >> >> GDB has relocatable paths that it adjusts based on where GDB is running on the >> target system. Those settings will be shown by the command Pedro suggested. >> >> For instance, one of the entries: >> >> --with-separate-debug-dir=/usr/lib/debug (relocatable) >> >> With that said, \\lib\debug seems a a bit odd, and there might be something off >> there unless your filesystem is NFS-mounted. >> >>> >>> Thanks, >>> Adrian >>> >>> >>> > > GDB 12: > (gdb) show version > GNU gdb (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 12.1.90.20221210-git > (gdb) show configuration > This GDB was configured as follows: > configure --host=i686-w64-mingw32 --target=arm-none-eabi > --with-auto-load-dir=$debugdir:$datadir/auto-load > --with-auto-load-safe-path=$debugdir:$datadir/auto-load > --with-expat > --with-gdb-datadir=//share/gdb (relocatable) > --with-jit-reader-dir=//lib/gdb (relocatable) > --without-libunwind-ia64 > --without-lzma > --without-babeltrace > --without-intel-pt > --with-mpfr > --without-xxhash > --without-python > --without-python-libdir > --without-debuginfod > --without-guile > --disable-source-highlight > --with-separate-debug-dir=//lib/debug (relocatable) > > GDB 10: > (gdb) show version > GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.10) 10.2.90.20210621-git > (gdb) show configuration > This GDB was configured as follows: > configure --host=i686-w64-mingw32 --target=arm-none-eabi > --with-auto-load-dir=$debugdir:$datadir/auto-load > --with-auto-load-safe-path=$debugdir:$datadir/auto-load > --with-expat > --with-gdb-datadir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/arm-none-eabi/share/gdb (relocatable) > --with-jit-reader-dir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/lib/gdb (relocatable) > --without-libunwind-ia64 > --without-lzma > --without-babeltrace > --without-intel-pt > --without-mpfr > --without-xxhash > --without-python > --without-python-libdir > --without-debuginfod > --without-guile > --disable-source-highlight > --with-separate-debug-dir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/lib/debug (relocatable) > --with-system-gdbinit=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/i686-w64-mingw32/arm-none-eabi/lib/gdbinit (relocatable) > >> With that said, \\lib\debug seems a a bit odd, and there might be something off >> there unless your filesystem is NFS-mounted. Thanks for the information above. That's very useful. > > Is the described behavior specific to the Windows image I have? Maybe... I don't know... > But it's a fact that the default 'debug-file-directory' that's configured in GDB 12 introduces some > unwanted side effects for me. If I 'set debug-file-directory' before issuing a 'symbol-file', > everything's fine. I'm assuming, given the network-like path, the Windows-hosted version of gdb will cause such issues when gdb does looking for the symbols. Let me try to gather some information on how gdb was built for these toolchains. > > Adrian