From: Tom Tromey <tromey@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org, Keith Seitz <keiths@redhat.com>
Subject: Re: [patch] Fix duplicate types for single DIE
Date: Fri, 04 Jun 2010 22:47:00 -0000 [thread overview]
Message-ID: <m3vd9ys9dk.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20100513115029.GA27341@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Thu, 13 May 2010 13:50:29 +0200")
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> Keith has provided "obstack-leak.patch" there as a prerequisite for
Jan> the physname patch there. Attaching here a more complete solution
Jan> of the problem.
I think it makes sense. Thanks for doing this.
Jan> On 250MB webkit debuginfo it reduced memory consumption by 3MB from
Jan> 4616MB (0.06%) (which is less than I hoped for; checked with
Jan> Keith's physname patch). I have not found measureable any
Jan> performance difference.
FWIW I've been thinking for a while about how we could "intern" types to
reduce memory use. However, it seems simpler expensive to just wait for
the .debug_types-enabled GCC to be deployed everywhere; also this
approach means no performance hit for GDB.
Jan> Tom Tromey may not agree with new internal_error as expressed in
Jan> Re: [patch] Fix dwarf2read to crash again
Jan> http://sourceware.org/ml/gdb-patches/2010-04/msg00812.html
Jan> I am not sure what are his specific plans; if some TRY_CATCH should be
Jan> involved the new internal_error call should OK there.
I am still going to get back to this eventually -- I took a long detour
through DW_OP_*piece.
I don't have a concrete plan other than to find appropriate places in
the DWARF reader to catch exceptions and arrange to do something
sensible.
I don't have a problem with an internal_error if it can only trigger
when there is a bug in GDB. If strange-but-valid DWARF can trigger it,
then I think it should be a complaint or maybe an ordinary error.
Jan> With the new internal_error call I have verified at least the fixes
Jan> of read_tag_pointer_type and read_tag_const_type fixes (and not
Jan> just these two) to be required. Other fixes are just written
Jan> artificially to cover all the cases of any indirect call of
Jan> tag_type_to_type, that is die_type, die_descriptive_type,
Jan> set_descriptive_type and die_containing_type. (I believe at least
Jan> those *_descriptive_type are in fact never needed as their DWARF
Jan> usage should never lead to DWARF references loops.)
Thanks.
Jan> 2010-05-13 Jan Kratochvil <jan.kratochvil@redhat.com>
Jan> * dwarf2read.c (read_structure_type): Move set_descriptive_type after
Jan> set_die_type.
Jan> (read_array_type): Remove type initialization. Recheck get_die_type
Jan> after initial die_type. Move set_die_type before set_descriptive_type.
Jan> (read_set_type): New variable domain_type. Recheck get_die_type after
Jan> initial die_type.
Jan> (read_tag_pointer_type, read_tag_reference_type): New variable
Jan> target_type. Recheck get_die_type after initial die_type.
Jan> (read_tag_ptr_to_member_type): Recheck get_die_type after initial
Jan> die_type and die_containing_type.
Jan> (read_tag_const_type, read_tag_volatile_type, read_subroutine_type):
Jan> Recheck get_die_type after initial die_type.
Jan> (read_subrange_type): Recheck get_die_type after initial die_type.
Jan> Move set_die_type before set_descriptive_type.
Jan> (set_die_type): Call internal_error if DIE has some type already set.
This patch is ok. I'm sorry for the delay in the review.
I did not look closely to see if this conflicts with Keith's
obstack-leak.patch. If so, it doesn't matter to me if that goes in and
then you back it out, or if Keith just doesn't commit it.
Tom
next prev parent reply other threads:[~2010-06-04 22:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-13 13:18 Jan Kratochvil
2010-05-20 23:35 ` Joel Brobecker
2010-05-21 12:18 ` Jan Kratochvil
2010-05-21 15:09 ` Joel Brobecker
2010-06-04 22:47 ` Tom Tromey [this message]
2010-06-05 14:55 ` Jan Kratochvil
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=m3vd9ys9dk.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--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