Slow "symbol-file" when using GDB 12.1 on Windows hosts

[Luis Machado]

On 3/17/23 18:49, Eli Zaretskii wrote:
>> Date: Fri, 17 Mar 2023 17:29:27 +0000
>> From: Luis Machado <luis.machado@arm.com>
>>
>> On 3/15/23 15:50, Adrian Oltean via Gdb wrote:
>>> Hi,
>>>
>>> We recently upgraded the GDB version (from 10.3 to 12.1) in one of our IDEs and
>>> found a painful performance issue on some Windows-based machines. I used
>>> Process Monitor to identify the events that occur during a "symbol-file" invocation.
>>> This is the command that now (GDB 12.1) seems to take ~2 seconds in the most
>>> favorable case, and ~20 seconds in the worst case (on some machines). Note that
>>> this happens with basic/small ELF files. Moreover, in GDB 10.3 execution of
>>> "symbol-file" is almost instant.
>>>
>>> The relevant list of events reported by Process Monitor is the following:
>>> Time of Day,Process Name,PID,Operation,Path,Result,Detail
>>> 43:02.7, arm-none-eabi-gdb.exe, 13604, ReadFile, C:\MyIDE\workspace\MyProject\Debug\MyProject.axf, SUCCESS, "Offset: 272,405, Length: 512"
>>> 43:02.7, arm-none-eabi-gdb.exe, 13604, CreateFile, C:\MyIDE\workspace\MyProject\Debug , SUCCESS, "Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened"
>>> 43:02.7, arm-none-eabi-gdb.exe, 13604, QueryDirectory,C:\MyIDE\workspace\MyProject\Debug\MyProject.axf.dwp, NO SUCH FILE, "FileInformationClass: FileBothDirectoryInformation, Filter: MyProject.axf.dwp"
>>> 43:02.7, arm-none-eabi-gdb.exe, 13604, CloseFile, C:\MyIDE\workspace\MyProject\Debug,SUCCESS,
>>> 43:02.7, arm-none-eabi-gdb.exe, 13604, CreateFile, C:\MyIDE\workspace\MyProject\Debug\Users\MyUsername\Documents\MyIDE\workspace\MyProject\Debug\, PATH NOT FOUND, "Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
>>> 43:02.7, arm-none-eabi-gdb.exe, 13604, CreateFile, C:\Users\MyUsername\Users\MyUsername\Documents\MyIDE\workspace\MyProject\Debug\, PATH NOT FOUND, "Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
>>> 43:05.9, arm-none-eabi-gdb.exe, 13604, CreateFile, C:\Windows\CSC\v2.0.6\namespace\lib, NAME NOT FOUND, "Desired Access: Read EA, Write EA, Read Attributes, Write Attributes, Delete, Read Control, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
>>> 43:05.9, arm-none-eabi-gdb.exe, 13604, CreateFile, \\lib\debug\Users\MyUsername\Documents\MyIDE\workspace\MyProject\Debug\,BAD<file://lib/debug/Users/MyUsername/Documents/MyIDE/workspace/MyProject/Debug/,BAD> NETWORK PATH, "Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
>>> 43:05.9, arm-none-eabi-gdb.exe, 13604, CreateFile, C:\Windows\CSC\v2.0.6\namespace\lib, NAME NOT FOUND, "Desired Access: Read EA, Write EA, Read Attributes, Write Attributes, Delete, Read Control, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
>>> 43:05.9, arm-none-eabi-gdb.exe, 13604, CreateFile, C:\MyIDE\workspace\MyProject\Debug, SUCCESS, "Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened"
>>> 43:05.9, arm-none-eabi-gdb.exe, 13604, QueryDirectory, C:\MyIDE\workspace\MyProject\Debug\MyProject.axf.dwp, NO SUCH FILE, "FileInformationClass: FileBothDirectoryInformation, Filter: MyProject.axf.dwp"
>>>
>>> I see attempts to read files/folders that aren't actually present on my machine. Also,
>>> a folder like "C:\Windows\CSC" (see "C:\Windows\CSC\v2.0.6\namespace\lib" above) isn't
>>> accessible on my machine without admin privileges (I don't have this, according to
>>> company policy). I observe that an attempt to access such a file/folder (or a network-specific
>>> path) hangs GDB for a few seconds. Questions:
>>>
>>>     1.  Is GDB trying to find debug symbols in all those folders? Or what's with them?
>>>     2.  What is the code from GDB that artificially builds all those paths?
>>>     3.  GDB 10.2 does not seem to access "C:\Windows\CSC\v2.0.6\namespace\lib", nor
>>> "\\lib\debug\Users\MyUsername\...<file://lib/debug/Users/MyUsername/...>". Is this related to a recent change? Can someone
>>> point to the relevant change in this case?
>>>
>>>     1.  Is there a command to stop GDB from attempting to access those files/folders?
>>>
>>> Thank you,
>>> Adrian
>>
>> I vaguely remember Eli ran into Windows-hosted gdb slowdowns before, but I'm not sure if it is related
>> to what's been described here.
>>
>> Eli?
> 
> That problem was solved.  And it was with GDB 13, not GDB 12.
> 
> I actually am not sure the fact that GDB looks in several directories
> has anything to do with slowdown in symbol-file.  The timeline
> presented by the OP shows just one directory accessing which allegedly
> takes 3 seconds, and I'm not sure what to make of that.  In any case,
> showing elapsed time on a modern system doesn't constitute a clear
> evidence that there's some heavy processing involved.
> 
> I guess what I'm saying is that more information is needed, perhaps
> with profile-quality timing data, to see what is going on here and
> what could cause a slowdown.

Thanks for the feedback.

There used to be an issue with ld (fixed in 2.37, https://sourceware.org/bugzilla/show_bug.cgi?id=27590)
that caused gdb to keep expanding CU's, causing a lot of CPU and memory usage.

We might need a bit more information on versions and tools involved to be able to provide some input.