Re: [PATCH] Fix "start" for D, Rust, etc

[Tom Tromey <tom@tromey.com>]

>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> 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
languages.

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.

Tom