Re: possible fix for PR symtab/23010

Joel Brobecker
2018-05-30T20:55:54Z

> [WARNING: Very long explanation enclosed. Skip to end if interested in
> conclusions.]

This is extremely useful in understanding the source of the problem,
and therefore the solution. A bit thank you for writing it up.

> And that is the cause of these problems. The call to
> prepare_one_comp_unit needs to be the *first* thing that is done when
> reading a CU so that the CU's language can be recorded (and inherited
> by any referenced partial_units).
>
> So, alas, this is the near trivial patch to fix this dictionary/symbol
> assertion in insert_symbol_hashed:

I agree with Tom; very nice investigative work, and the near trivial
patch feels like gravy.

>
> diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
> index 49ce83ff20..0145c83b30 100644
> --- a/gdb/dwarf2read.c
> +++ b/gdb/dwarf2read.c
> @@ -11470,6 +11470,8 @@ read_file_scope (struct die_info *die, struct dwarf2_cu *cu)
> struct die_info *child_die;
> CORE_ADDR baseaddr;
>
> + prepare_one_comp_unit (cu, die, cu->language);
> +
> baseaddr = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
>
> get_scope_pc_bounds (die, &lowpc, &highpc, cu);
> @@ -11482,8 +11484,6 @@ read_file_scope (struct die_info *die, struct dwarf2_cu *cu)
>
> file_and_directory fnd = find_file_and_directory (die, cu);
>
> - prepare_one_comp_unit (cu, die, cu->language);
> -
> /* The XLCL doesn't generate DW_LANG_OpenCL because this attribute is not
> standardised yet. As a workaround for the language detection we fall
> back to the DW_AT_producer string. */
>

I looked at the patch, and in particular, checked to see if there
is anything we were doing ahead of the call to prepare_one_comp_unit
that prepare_one_comp_unit would also need. But this function
does very little, basically reading the DW_AT_language and
the DW_AT_producer attributes. So I don't see how this could have
some negative side-effect, or any hints of why it might have been
placed slight later in read_file_scope's body.

A testcase in this particular case, where the order in which we do
things is important, would be very useful in avoiding a regression.
However, considering how specific the conditions need to be in order
to trigger the bug, and considering the current timing, I (personally)
think that we should not let best be the enemy of good, and allow
this patch in if Keith fails to create a testcase after a reasonable
amount of effort.

--
Joel