Re: [PATCH 1/2] [gdb/symtab] Add name_of_main and language_of_main to the DWARF index

[Tom de Vries <tdevries@suse.de>]

On 10/23/23 18:26, Aaron Merey wrote:
> Hi Tom,
> 
> I tried to generate a v9 .gdb_index for a hello world C program and
> for my local gdb build.  In both cases the name and language of the main
> function are missing.  I looked into this and it seems that main
> information is set in the index only when DW_AT_main_subprogram
> is found or DW_AT_calling_convention == DW_CC_program.
> 
>  From gcc/dwarf2out.cc:add_calling_convention_attribute it looks like
> DW_AT_main_subprogram is only set for Fortran programs.  And as far as
> I can tell DW_AT_calling_convention is not set for C/C++ programs.
> 
> Am I missing something or is the range of cases where a v9 index actually
> contains the name and laguage of main quite limited?  When writing an index
> maybe gdb should try to infer the main name and language from the current
> progspace if this information isn't available in the debuginfo.

Hi,

the current approach is to store information in the dwarf index that is 
available in the dwarf (more concretely, found by the cooked-index's 
get_main).

The benefits are:
- correctness (fixing the case that main_subprogram is ignored when we
   have a .gdb_index, which was my main concern (PR24549))
- speed (in the cases that it covers).

I tried out the C hello world with .gdb_index added, and indeed we end 
up expanding the CU to get the name of main, which can be slow if the CU 
is large (as the author points out in the commit log).  So agreed, we 
can add more cases for speed.

Implementation-wise, that looks non-trivial.

There are two paths to writing a .gdb_index:
- the save gdb-index command
- the index-cache.

In the former case, it's probably fairly easy to infer the main name and 
language from the current progspace, as you suggest, since 
set_initial_language has been executed already.

In the latter case, writing the index-cache is executed asap in the 
background, and it only waits for the cooked-index to become available. 
So it would have to wait for the result of set_initial_language as well.

Also (for both cases) some thought will have to go into how to handle 
the case that the initial language is set by the user.  Is that the 
language we want to write into the .gdb_index?  Or do we skip writing it 
in that case?  Or do we try to get the auto-detected initial language by 
running set_initial_language on the main thread at the point that we 
need it?  Or do we try to get the auto-detected initial language in the 
background on a worker thread?

Thanks,
- Tom