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: Friday, March 17, 2023 9:02 PM
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: Adrian Oltean <adrian.oltean@nxp.com>; gdb@sourceware.org
> Subject: [EXT] Re: Slow "symbol-file" when using GDB 12.1 on Windows hosts
> 
> Caution: EXT Email
> 
> 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\M
> yIDE\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/works
> pace/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,
> 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.

Thanks for your comments. What kind of extra information would be helpful? I mentioned
in my previous email that the problematic GDB is v12.1 and the reference GDB
that seems fine is GDB v10.2. Releases can be downloaded from
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

Eli mentioned that the timestamps offered by Process Monitor are not relevant. However,
I consider that the events and their timestamps are relevant when compared to the
ones generated by GDB 10. There's no attempt to access "C:\Windows\CSC" when
using GDB 10. If that file access wouldn't be attempted by GDB 12, I'm pretty sure
there wouldn't be any slowdown. By the way, there's no spike in CPU/memory usage
when invoking "symbol-file" but, on my PC, "C:\Windows\CSC" is completely inaccessible
with my user account.

Maybe you guys can also answer (some of) the questions from my initial email?

Thank you,
Adrian