public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Adrian Oltean <adrian.oltean@nxp.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "luis.machado@arm.com" <luis.machado@arm.com>,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: RE: [EXT] Re: Slow "symbol-file" when using GDB 12.1 on Windows hosts
Date: Mon, 20 Mar 2023 13:33:49 +0000	[thread overview]
Message-ID: <AM6PR04MB4630F94FF5442C662C5121F0F1809@AM6PR04MB4630.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <AM6PR04MB4630EEC14E1C39817D7DB47CF1809@AM6PR04MB4630.eurprd04.prod.outlook.com>



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

  reply	other threads:[~2023-03-20 13:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-15 15:50 Adrian Oltean
2023-03-17 17:29 ` Luis Machado
2023-03-17 18:49   ` Eli Zaretskii
2023-03-17 19:02     ` Luis Machado
2023-03-20 12:29       ` Adrian Oltean
2023-03-20 13:19         ` Eli Zaretskii
2023-03-20 13:27           ` [EXT] " Adrian Oltean
2023-03-20 13:33             ` Adrian Oltean [this message]
2023-03-20 13:58               ` Eli Zaretskii
2023-03-22 14:30                 ` Luis Machado
2023-04-03 16:48                   ` Adrian Oltean
2023-04-04 12:53                     ` Pedro Alves
2023-04-04 13:02                     ` Luis Machado
2023-04-04 14:07                       ` Adrian Oltean
2023-04-04 14:15                         ` Luis Machado
2023-04-04 14:17                         ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM6PR04MB4630F94FF5442C662C5121F0F1809@AM6PR04MB4630.eurprd04.prod.outlook.com \
    --to=adrian.oltean@nxp.com \
    --cc=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=luis.machado@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).