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

[Luis Machado <luis.machado@arm.com>]

On 4/4/23 15:07, Adrian Oltean wrote:
>> -----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.

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