RE: [EXT] Re: Slow "symbol-file" when using GDB 12.1 on Windows hosts

[Adrian Oltean <adrian.oltean@nxp.com>]

> -----Original Message-----
> From: Luis Machado <luis.machado@arm.com>
> Sent: Tuesday, April 4, 2023 4:02 PM
> To: Adrian Oltean <adrian.oltean@nxp.com>; Eli Zaretskii <eliz@gnu.org>
> Cc: gdb@sourceware.org
> 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 <luis.machado@arm.com>
> >> Sent: Wednesday, March 22, 2023 4:31 PM
> >> To: Eli Zaretskii <eliz@gnu.org>; Adrian Oltean
> >> <adrian.oltean@nxp.com>
> >> Cc: gdb@sourceware.org
> >> 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