Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.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: Thu, 20 May 2010 23:35:00 -0000	[thread overview]
Message-ID: <20100520233131.GN3019@adacore.com> (raw)
In-Reply-To: <20100513115029.GA27341@host0.dyn.jankratochvil.net>

> Tom Tromey may not agree with new internal_error as expressed in
> 	Re: [patch] Fix dwarf2read to crash again
> 	http://sourceware.org/ml/gdb-patches/2010-04/msg00812.html
> I am not sure what are his specific plans; if some TRY_CATCH should be
> involved the new internal_error call should OK there.

This is a situation where we can recover without much hassle by just
allocating a new slot, so I'd just emit a complaint, and allow the
user to continue debugging.

> 2010-05-13  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	* dwarf2read.c (read_structure_type): Move set_descriptive_type after
> 	set_die_type.
> 	(read_array_type): Remove type initialization.  Recheck get_die_type
> 	after initial die_type.  Move set_die_type before set_descriptive_type.
> 	(read_set_type): New variable domain_type.  Recheck get_die_type after
> 	initial die_type.
> 	(read_tag_pointer_type, read_tag_reference_type): New variable
> 	target_type.  Recheck get_die_type after initial die_type.
> 	(read_tag_ptr_to_member_type): Recheck get_die_type after initial
> 	die_type and die_containing_type.
> 	(read_tag_const_type, read_tag_volatile_type, read_subroutine_type):
> 	Recheck get_die_type after initial die_type.
> 	(read_subrange_type): Recheck get_die_type after initial die_type.
> 	Move set_die_type before set_descriptive_type.
> 	(set_die_type): Call internal_error if DIE has some type already set.

I skimmed through the patch, and it looks reasonable.  But I don't
feel comfortable approving it - don't know that file well enough
anymore. Sorry.

There's something I can seem to be able to understand: Why does
set_descriptive_type need to be called after set_die_type? I mean,
from a conceptual point of view, it sort of makes sense. But I can't
see how in practice changing the call order makes any difference...
-- 
Joel


  reply	other threads:[~2010-05-20 23:31 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 [this message]
2010-05-21 12:18   ` Jan Kratochvil
2010-05-21 15:09     ` Joel Brobecker
2010-06-04 22:47 ` Tom Tromey
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=20100520233131.GN3019@adacore.com \
    --to=brobecker@adacore.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