RE: [EXT] Re: Slow "symbol-file" when using GDB 12.1 on Windows hosts
Adrian Oltean via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <AM6PR04MB463051BCB46635A68C964DEBF1939@AM6PR04MB4630.eurprd04.prod.outlook.com> |
> -----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. 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. Adrian