From: Tom Tromey <tom@tromey.com>
To: Keith Seitz <keiths@redhat.com>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: possible fix for PR symtab/23010
Date: Thu, 17 May 2018 17:16:00 -0000 [thread overview]
Message-ID: <87a7sygspz.fsf@tromey.com> (raw)
In-Reply-To: <f163fa84-eb60-ac12-dedb-b6970b799165@redhat.com> (Keith Seitz's message of "Tue, 17 Apr 2018 12:17:00 -0700")
>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:
Keith> This patch looks reasonable to me, but I would ask you to consider
Keith> mentioning why partial_units are skipped where they are (even if to
Keith> just reference the problem or bug?). That's these two hunks, I think:
>> diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
>> index e3f544a6a4..406aa0d52e 100644
>> --- a/gdb/dwarf2read.c
>> +++ b/gdb/dwarf2read.c
>> @@ -2870,7 +2870,7 @@ dw2_do_instantiate_symtab (struct dwarf2_per_cu_data *per_cu)
>> : (per_cu->v.psymtab == NULL || !per_cu->v.psymtab->readin))
>> {
>> queue_comp_unit (per_cu, language_minimal);
>> - load_cu (per_cu);
>> + load_cu (per_cu, true);
>>
>> /* If we just loaded a CU from a DWO, and we're working with an index
>> that may badly handle TUs, load all the TUs in that DWO as well.
This use of "true" actually seems weird to me on re-reading.
dw2_do_instantiate_symtab doesn't actually use the skip_partial
parameter I added.
So, I changed this to pass skip_partial to load_cu.
I verified that the -readnow test on libwebkit2gtk still works.
>> @@ -4144,7 +4144,7 @@ dw2_expand_all_symtabs (struct objfile *objfile)
>> {
>> dwarf2_per_cu_data *per_cu = dwarf2_per_objfile->get_cutu (i);
>>
>> - dw2_instantiate_symtab (per_cu);
>> + dw2_instantiate_symtab (per_cu, true);
>> }
>> }
>>
Here I added this comment:
/* We don't want to directly expand a partial CU, because if we
read it with the wrong language, then assertion failures can
be triggered later on. See PR symtab/23010. So, tell
dw2_instantiate_symtab to skip partial CUs -- any important
partial CU will be read via DW_TAG_imported_unit anyway. */
I looked at your test case a bit but I also couldn't make it fail.
I'm pushing this patch in now.
Tom
prev parent reply other threads:[~2018-05-17 16:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-12 19:06 Tom Tromey
2018-04-17 19:17 ` Keith Seitz
2018-04-19 20:39 ` Tom Tromey
2018-04-30 22:44 ` Joel Brobecker
2018-05-07 17:13 ` Joel Brobecker
2018-05-14 19:43 ` Joel Brobecker
2018-05-18 1:22 ` Sergio Durigan Junior
2018-05-24 4:08 ` Tom Tromey
2018-05-24 10:50 ` Sergio Durigan Junior
2018-05-24 10:50 ` Tom Tromey
2018-05-24 15:54 ` Keith Seitz
2018-05-26 0:24 ` Keith Seitz
2018-05-27 15:20 ` Tom Tromey
2018-05-30 22:26 ` Joel Brobecker
2018-05-17 17:16 ` 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:
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=87a7sygspz.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=keiths@redhat.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