public inbox for
 help / color / mirror / Atom feed
From: Tom Tromey <>
To: Andrew Burgess <>
Cc: Tom Tromey <>,
Subject: Re: [PATCH] Fix "start" for D, Rust, etc
Date: Fri, 17 Feb 2023 18:42:08 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Andrew Burgess's message of "Fri, 17 Feb 2023 22:26:50 +0000")

>>>>> "Andrew" == Andrew Burgess <> writes:

>> A long time ago, in an earlier threading attempt, I changed the global
>> current_language to be a function (hidden behind a macro) to let us
>> attempt lazily computing the current language.  Perhaps this approach
>> could still be made to work.  However, that also seemed rather tricky,
>> more so than this patch.

Andrew> ... I don't understand what this last paragraph has to do with the
Andrew> problem being solved here.

Yeah, it's kind of tangential.  Essay follows.

In an ideal world, gdb would scan the DWARF, and if it saw
DW_AT_main_subprogram, it would use that name.

That doesn't fully work because gdb requires canonicalization.  (Maybe
all debuggers do in some way or another, but gdb chooses to do it during
scanning, so it affects the user-visible startup time.)

gdb makes a second choice here, which is to use the "main" to set the
initial language and context.

So, if gdb scans the DWARF and waits for canonicalization in order to
use "main", then users will wait the entire time it takes... whereas
right now, we hide some of this by canonicalizing in a worker thread.

This patch preserves this feature by deciding to only handle a subset of

Another possibility would be to delay the search for "main".  When the
user runs "gdb program" and the prompt appears, there's no real need to
pre-emptively find "main".  Instead, it can be deferred until the first
command that actually requires it.

That's what this earlier patch did.  IIRC, I added a "#define" for
current_language that would compute it when first needed.  I think this
required some hacks as well (at the time I think Python initialization
wanted the language).

Another possible approach here would be to canonicalize just the "main"
entry and its parent entries when needed.  This is some annoying
bookkeeping but maybe not too bad.

It's worth noting, though, that elsewhere I'm working on patches to move
more of the DWARF reader into worker threads.  There, the idea is to
start the DWARF reader immediately in dwarf2_has_info (in the
background).  If we had lazy current_language setting, this work would
make the user experience even faster startup times (sometimes).  With
the current shape of the patches, the difference is small for the "file"
case (it's more aimed at "attach"), because, once again, gdb has to wait
for the DWARF reader to dig up that DW_AT_main_subprogram.

Speeding up DWARF reading is pretty hard.  Partly this is because DWARF
is bad, but partly it's due to choices gdb makes.  However, since it's
regularly the slowest thing users encounter, IMO it's worth the extra
effort both to try to hide the costs, and also to try to think of
alternative solutions that perform well.

Andrew> I have a couple of _really_ minor comment fixes that I think would help,
Andrew> and one small code suggestion.  See inline below.

I'll fix all these up.

>> cu {} {
>> +	# Note we don't want C here as that requires canonicalization.
>> DW_TAG_compile_unit {
>> -                {DW_AT_language @DW_LANG_C}
>> +		{DW_AT_language @DW_LANG_PLI}

Andrew> I'm curious why PLI?  I guess it's to force GDB to select language
Andrew> minimal, but this is so weird it feels like it's worth a comment.

There's the "don't want C" comment but I will expand it.

Anyway I chose a language that gdb is unlikely to support and also that
made me laugh.  Normally of course this would be COBOL, but a GCC front
end for COBOL is going in so...

Thanks for the review.


      reply	other threads:[~2023-02-18  1:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-14  3:00 Tom Tromey
2023-02-16 18:28 ` Tom Tromey
2023-02-17 22:26 ` Andrew Burgess
2023-02-18  1:42   ` Tom Tromey [this message]

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:

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

  git send-email \ \ \ \ \

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