This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix duplicate types for single DIE


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]