Re: possible fix for PR symtab/23010

[Joel Brobecker <brobecker@adacore.com>]

> [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