[PATCH 3/3] [gdb/symtab] Don't expand non-Ada CUs for info exceptions

[Tom de Vries]

On 9/20/24 20:54, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
> 
> Tom> Fix this by:
> Tom> - adding a new lang_matcher parameter to the expand_symtabs_matching
> Tom>   function, and
> Tom> - using that new parameter in the expand_symtabs_matching call in
> Tom>   ada_add_global_exceptions.
> 
> Thanks for doing this.
> 
> Tom> Conversely, when processing a CU with language C and name "<artificial>"
> Tom> (as produced by GCC LTO), the CU may not really have a single language and we
> Tom> should ignore the lang_matcher.  See also commit d2f67711730
> Tom> ("Fix 'catch exception' with -flto").
> 
> Not your fault at all, but wow this is gross.
> 
> I guess DWARF will need some kind of extension to handle this sort of
> thing properly... and then if it does, gdb is going to need a fair
> amount of work as well.
> 
> The main issue I see is that we have all kinds of special cases based on
> the CU language.  In LTO mode right now, of course, these won't trigger;
 > and so I suspect that really debugging LTO will have a lot of buggy
 > behavior.

If I run test-case gdb.ada/info_exc.exp with target board 
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, then the 
artificial CU that is produced has language ADA 95, because it's not a 
multi-language compilation, and the special cases do trigger and manage 
to skip 18 CUs (with c and asm language from objects that were linked 
into the exec, but were not part of the LTO scope).

But indeed, with a single-language C compilation and LTO we're out of 
luck.  [ Typically an artificial LTO CU has imports, and we could 
iterate over the imports to find whether it's an single-language CU or 
not.  But I remember asking for GCC to stop emitting this, because 
importing a C++ CU into another CU declares the symbols twice.  I added 
a workaround for this marked with "We're importing a C++ compilation 
unit with tag DW_TAG_compile_unit" in dwarf2/read.c.  BTW that 
workaround could also use the ensure_lang treatment. ]

> Tom> +  std::unordered_set<enum language> unique_styles_used;
> Tom> +  if (lang_matcher != nullptr)
> Tom> +    for (unsigned iter = 0; iter < nr_languages; ++iter)
> Tom> +      {
> Tom> +	enum language lang = (enum language)iter;
> 
> Normally a space after the ")".
> 

Fixed.

> Instead of unordered_set here, other spots with a similar need in gdb
> use a bitset or an array:
> 
>    std::bitset<nr_languages> demangled_hash_languages;
>    mutable std::array<unsigned int, nr_languages> m_demangled_hashes;
>    mutable std::array<bool, nr_languages> m_demangled_hashes_p {};
> 
> One of these would be more efficient.
> 

I've used a std::bitset.

> Alternatively, though, I guess this code could be changed:
> 
> Tom>    for (enum language lang : unique_styles)
> Tom>      {
> Tom> +      if (lang_matcher != nullptr
> Tom> +	  && unique_styles_used.count (lang) == 0)
> Tom> +	continue;
> 
> Here this could just call lang_matcher -- but on failure, if lang has
> multiple matches, it could make a second call.
> 

I'm not sure I understand what you mean, but your remark made me realize 
that we could compute unique_styles_used lazily.  It's only necessary if
lang_matcher returns false for at least one of the unique_styles.

But I suppose with the current set of lang_matcher values that is not 
necessary, so I've left it out of v2 ( 
https://sourceware.org/pipermail/gdb-patches/2024-September/211822.html ).

Thanks,
- Tom

> Not your problem but this unique_styles stuff is pretty lame really.
> 
> Tom