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

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

[Adrian Oltean]

[-- Attachment #1: Type: text/plain, Size: 4621 bytes --]

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

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

[Luis Machado]

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?

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

[Eli Zaretskii]

> 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.

Re: 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.

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

[Adrian Oltean]

> -----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

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

[Eli Zaretskii]

> From: Adrian Oltean <adrian.oltean@nxp.com>
> CC: "gdb@sourceware.org" <gdb@sourceware.org>
> Date: Mon, 20 Mar 2023 12:29:25 +0000
> 
> 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.

Any idea why GDB is accessing all those directories?  I cannot know
what kind of directory structure you have there, and so cannot reason
about the directories being accessed by GDB or whether it should
access some directory.  What are those directories, and why
symbol-file causes GDB to access them?

> 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.

That is probably the real culprit: some directory that needs some
special credentials, or which causes GDB to call some network-related
resources which are inaccessible or something.  So understanding why
GDB tries to access that directory and/or making its access faster,
might fix your problem.

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

Which ones?

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

[Adrian Oltean]

> -----Original Message-----
> From: Eli Zaretskii <eliz@gnu.org>
> Sent: Monday, March 20, 2023 3:19 PM
> To: Adrian Oltean <adrian.oltean@nxp.com>
> Cc: luis.machado@arm.com; gdb@sourceware.org
> Subject: [EXT] Re: Slow "symbol-file" when using GDB 12.1 on Windows hosts
> 
> Caution: EXT Email
> 
> > From: Adrian Oltean <adrian.oltean@nxp.com>
> > CC: "gdb@sourceware.org" <gdb@sourceware.org>
> > Date: Mon, 20 Mar 2023 12:29:25 +0000
> >
> > 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.
> 
> Any idea why GDB is accessing all those directories?  I cannot know what kind
> of directory structure you have there, and so cannot reason about the
> directories being accessed by GDB or whether it should access some
> directory.  What are those directories, and why symbol-file causes GDB to
> access them?

I was thinking that GDB starts inspecting some known locations (e.g. location of the elf).
I don't think GDB is so unpredictable when it comes to what files/directories
needs to access when "symbol-file" is issued... Or is it? 

> > 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.
> 
> That is probably the real culprit: some directory that needs some special
> credentials, or which causes GDB to call some network-related resources
> which are inaccessible or something.  So understanding why GDB tries to
> access that directory and/or making its access faster, might fix your problem.

Indeed... Why is GDB trying to access "client-side caching" folder from Windows? I'm
pretty sure this is not specific to my machine.

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

You, Luis or anyone else... :-)

Thank you,
Adrian

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

[Adrian Oltean]

> -----Original Message-----
> From: Adrian Oltean
> Sent: Monday, March 20, 2023 3:28 PM
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: luis.machado@arm.com; gdb@sourceware.org
> Subject: RE: [EXT] Re: Slow "symbol-file" when using GDB 12.1 on Windows
> hosts
> 
> 
> 
> > -----Original Message-----
> > From: Eli Zaretskii <eliz@gnu.org>
> > Sent: Monday, March 20, 2023 3:19 PM
> > To: Adrian Oltean <adrian.oltean@nxp.com>
> > Cc: luis.machado@arm.com; gdb@sourceware.org
> > Subject: [EXT] Re: Slow "symbol-file" when using GDB 12.1 on Windows
> > hosts
> >
> > Caution: EXT Email
> >
> > > From: Adrian Oltean <adrian.oltean@nxp.com>
> > > CC: "gdb@sourceware.org" <gdb@sourceware.org>
> > > Date: Mon, 20 Mar 2023 12:29:25 +0000
> > >
> > > 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.
> >
> > Any idea why GDB is accessing all those directories?  I cannot know
> > what kind of directory structure you have there, and so cannot reason
> > about the directories being accessed by GDB or whether it should
> > access some directory.  What are those directories, and why
> > symbol-file causes GDB to access them?
> 
> I was thinking that GDB starts inspecting some known locations (e.g. location
> of the elf).
> I don't think GDB is so unpredictable when it comes to what files/directories
> needs to access when "symbol-file" is issued... Or is it?
> 
> > > 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.
> >
> > That is probably the real culprit: some directory that needs some
> > special credentials, or which causes GDB to call some network-related
> > resources which are inaccessible or something.  So understanding why
> > GDB tries to access that directory and/or making its access faster, might fix
> your problem.
> 
> Indeed... Why is GDB trying to access "client-side caching" folder from
> Windows? I'm pretty sure this is not specific to my machine.
> 
> > > Maybe you guys can also answer (some of) the questions from my
> > > initial
> > email?
> >
> > Which ones?
> 
> You, Luis or anyone else... :-)

Sorry... I misunderstood your question... (facepalm)

These were the 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\...". Is this related to a recent change? Can someone
point to the relevant change in this case?
4.	Is there a command to stop GDB from attempting to access those files/folders?

> 
> Thank you,
> Adrian

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

[Eli Zaretskii]

> From: Adrian Oltean <adrian.oltean@nxp.com>
> CC: "luis.machado@arm.com" <luis.machado@arm.com>, "gdb@sourceware.org"
> 	<gdb@sourceware.org>
> Date: Mon, 20 Mar 2023 13:33:49 +0000
> 
> These were the 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\...". Is this related to a recent change? Can someone
> point to the relevant change in this case?
> 4.	Is there a command to stop GDB from attempting to access those files/folders?

Sorry, I don't know the answers.  Maybe Luis or someone else does.

In general, AFAIK GDB searches directories recorded in the program's
debug info, and also some source directories.  See the node "Source
Path" in the GDB manual.  Also try "show solib-search-path".  The
"show libthread-db-search-path" command could also be relevant; see
"Threads" in the manual.

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

[Luis Machado]

On 3/20/23 13:58, Eli Zaretskii wrote:
>> From: Adrian Oltean <adrian.oltean@nxp.com>
>> CC: "luis.machado@arm.com" <luis.machado@arm.com>, "gdb@sourceware.org"
>> 	<gdb@sourceware.org>
>> Date: Mon, 20 Mar 2023 13:33:49 +0000
>>
>> These were the 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\...". Is this related to a recent change? Can someone
>> point to the relevant change in this case?
>> 4.	Is there a command to stop GDB from attempting to access those files/folders?
> 
> Sorry, I don't know the answers.  Maybe Luis or someone else does.
> 
> In general, AFAIK GDB searches directories recorded in the program's
> debug info, and also some source directories.  See the node "Source
> Path" in the GDB manual.  Also try "show solib-search-path".  The
> "show libthread-db-search-path" command could also be relevant; see
> "Threads" in the manual.

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.

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

[Adrian Oltean]

> -----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.

Thanks,
Adrian

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

[Pedro Alves]

On 2023-04-03 5:48 p.m., Adrian Oltean via Gdb wrote:

> 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.

"(gdb) show configuration" may help determine whether GDB was configured with such a
bad path.

Could be GDB is making up that path somehow, by concating "\" with "\lib\debug", for example.
If so, that might be fixed in GDB 13, as path joining was refactored/tweaked in that
release.

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

[Luis Machado]

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
> 
> 
> 

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

[Adrian Oltean]

> -----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

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

[Luis Machado]

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

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

[Pedro Alves]

On 2023-04-04 3:07 p.m., Adrian Oltean wrote:
> 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:
...
>              --with-separate-debug-dir=//lib/debug (relocatable)
                                         ^^^^^^^^^^^
> 

There you go, it's right there.

> 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:
...
>              --with-separate-debug-dir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/lib/debug (relocatable)
...

> Is the described behavior specific to the Windows image I have? Maybe... I don't know...

Looks like your GDB 12 was configured to look into that network path for separate debug files.

> 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.

The next question would be whether "--with-separate-debug-dir=//lib/debug" would be the default
on Windows GDB 12 for some reason, of whether it was explicitly specified in that build.  I would
hazard a guess that it's the latter, but you never know.