Patchwork [gdb/symtab] Support DW_AT_main_subprogram with -readnow.

login
register
mail settings
Submitter Tom de Vries
Date May 5, 2019, 10:25 a.m.
Message ID <20190505102520.GA5031@delia>
Download mbox | patch
Permalink /patch/32560/
State New
Headers show

Comments

Tom de Vries - May 5, 2019, 10:25 a.m.
Hi,

DW_AT_main_subprogram is supported in normal mode in read_partial_die, but not
in -readnow mode.

Fix this by adding support for DW_AT_main_subprogram in read_func_scope.

Tested on x86_64-linux with native and RFC target board readnow (
https://sourceware.org/ml/gdb-patches/2019-05/msg00073.html ).

OK for trunk?

Thanks,
- Tom

[gdb/symtab] Support DW_AT_main_subprogram with -readnow.

gdb/ChangeLog:

2019-05-05  Tom de Vries  <tdevries@suse.de>

	PR symtab/16264
	PR symtab/24517
	* dwarf2read.c (read_func_scope): Handle DW_AT_main_subprogram.

---
 gdb/dwarf2read.c | 4 ++++
 1 file changed, 4 insertions(+)
Tom de Vries - May 5, 2019, 11:42 a.m.
[ was: Re: [PATCH][gdb/symtab] Support DW_AT_main_subprogram with
-readnow. ]

Hi,

DW_AT_main_subprogram is supported in normal mode (in
read_partial_die),and tested by test-case gdb.dwarf2/main-subprogram.exp.

DW_AT_main_subprogram is currently not supported in -readnow mode, but
I've submitted a fix for that (in read_func_scope).

Still, the test-case gdb.dwarf2/main-subprogram.exp fails with
executables that contain an index, either .gdb_index or .debug_names
(which is exercised by target boards cc-with-gdb-index and
cc-with-debug-names).

I wonder whether and if so, how this should be fixed.

ISTM that we want gdb to behave the same, functionality-wise, in normal
mode, -readnow mode, and with an index.

AFAIU, to fix this, then when loading an executable with index into gdb
and issuing the start command, we'll need to read the debug info until
finding the DW_AT_main_subprogram, but reading the debug info scanning
just for one attribute seems rather inefficient to me.

Any comments or advice here?

Thanks,
- Tom
Tom de Vries - May 10, 2019, 7:57 a.m.
On 05-05-19 13:42, Tom de Vries wrote:
> [ was: Re: [PATCH][gdb/symtab] Support DW_AT_main_subprogram with
> -readnow. ]
> 
> Hi,
> 
> DW_AT_main_subprogram is supported in normal mode (in
> read_partial_die),and tested by test-case gdb.dwarf2/main-subprogram.exp.
> 
> DW_AT_main_subprogram is currently not supported in -readnow mode, but
> I've submitted a fix for that (in read_func_scope).
> 
> Still, the test-case gdb.dwarf2/main-subprogram.exp fails with
> executables that contain an index, either .gdb_index or .debug_names
> (which is exercised by target boards cc-with-gdb-index and
> cc-with-debug-names).
> 
> I wonder whether and if so, how this should be fixed.
> 
> ISTM that we want gdb to behave the same, functionality-wise, in normal
> mode, -readnow mode, and with an index.
> 
> AFAIU, to fix this, then when loading an executable with index into gdb
> and issuing the start command, we'll need to read the debug info until
> finding the DW_AT_main_subprogram, but reading the debug info scanning
> just for one attribute seems rather inefficient to me.
> 
> Any comments or advice here?

I just found in the DWARF-4 standard:
...
3.1.1 Normal and Partial Compilation Unit Entries
11. A DW_AT_main_subprogram attribute, which is a flag whose presence
indicates that the compilation unit contains a subprogram that has been
identified as the starting function of the program.
...

The test-case gdb.dwarf2/main-subprogram.exp doesn't contain this
attribute on the containing CU.

Also, gcc doesn't emit it, I just filed PR90422 - "DW_AT_main_subprogram
not added to CU DIE" (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90422 ) about that.

I imagine that scanning the CUs for this attribute shouldn't be too slow.

Thanks,
- Tom
Tom de Vries - May 13, 2019, 2:20 p.m.
On 10-05-19 09:57, Tom de Vries wrote:
> On 05-05-19 13:42, Tom de Vries wrote:
>> [ was: Re: [PATCH][gdb/symtab] Support DW_AT_main_subprogram with
>> -readnow. ]
>>
>> Hi,
>>
>> DW_AT_main_subprogram is supported in normal mode (in
>> read_partial_die),and tested by test-case gdb.dwarf2/main-subprogram.exp.
>>
>> DW_AT_main_subprogram is currently not supported in -readnow mode, but
>> I've submitted a fix for that (in read_func_scope).
>>
>> Still, the test-case gdb.dwarf2/main-subprogram.exp fails with
>> executables that contain an index, either .gdb_index or .debug_names
>> (which is exercised by target boards cc-with-gdb-index and
>> cc-with-debug-names).
>>
>> I wonder whether and if so, how this should be fixed.
>>
>> ISTM that we want gdb to behave the same, functionality-wise, in normal
>> mode, -readnow mode, and with an index.
>>
>> AFAIU, to fix this, then when loading an executable with index into gdb
>> and issuing the start command, we'll need to read the debug info until
>> finding the DW_AT_main_subprogram, but reading the debug info scanning
>> just for one attribute seems rather inefficient to me.
>>
>> Any comments or advice here?
> 
> I just found in the DWARF-4 standard:
> ...
> 3.1.1 Normal and Partial Compilation Unit Entries
> 11. A DW_AT_main_subprogram attribute, which is a flag whose presence
> indicates that the compilation unit contains a subprogram that has been
> identified as the starting function of the program.
> ...
> 
> The test-case gdb.dwarf2/main-subprogram.exp doesn't contain this
> attribute on the containing CU.
> 
> Also, gcc doesn't emit it, I just filed PR90422 - "DW_AT_main_subprogram
> not added to CU DIE" (
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90422 ) about that.
> 
> I imagine that scanning the CUs for this attribute shouldn't be too slow.
> 

Tracking this at Bug 24549 - "DW_AT_main_subprogram ignored with
cc-with-gdb-index/cc-with-debug-names" (
https://sourceware.org/bugzilla/show_bug.cgi?id=24549 ).

Thanks,
- Tom
Tom de Vries - May 17, 2019, 3:08 p.m.
On 05-05-19 12:25, Tom de Vries wrote:
> Hi,
> 
> DW_AT_main_subprogram is supported in normal mode in read_partial_die, but not
> in -readnow mode.
> 
> Fix this by adding support for DW_AT_main_subprogram in read_func_scope.
> 
> Tested on x86_64-linux with native and RFC target board readnow (
> https://sourceware.org/ml/gdb-patches/2019-05/msg00073.html ).
> 
> OK for trunk?
> 
> Thanks,
> - Tom
> 
> [gdb/symtab] Support DW_AT_main_subprogram with -readnow.
> 
> gdb/ChangeLog:
> 
> 2019-05-05  Tom de Vries  <tdevries@suse.de>
> 
> 	PR symtab/16264
> 	PR symtab/24517
> 	* dwarf2read.c (read_func_scope): Handle DW_AT_main_subprogram.
> 
> ---
>  gdb/dwarf2read.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
> index b5ea9e3cc0..3e611b0842 100644
> --- a/gdb/dwarf2read.c
> +++ b/gdb/dwarf2read.c
> @@ -13741,6 +13741,10 @@ read_func_scope (struct die_info *die, struct dwarf2_cu *cu)
>    newobj->name = new_symbol (die, read_type_die (die, cu), cu,
>  			     (struct symbol *) templ_func);
>  
> +  if (dwarf2_flag_true_p (die, DW_AT_main_subprogram, cu))
> +    set_objfile_main_name (objfile, SYMBOL_LINKAGE_NAME (newobj->name),
> +			   cu->language);
> +
>    /* If there is a location expression for DW_AT_frame_base, record
>       it.  */
>    attr = dwarf2_attr (die, DW_AT_frame_base, cu);
>
Tom Tromey - May 29, 2019, 1:37 p.m.
>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:

Tom> DW_AT_main_subprogram is supported in normal mode in read_partial_die, but not
Tom> in -readnow mode.

Tom> Fix this by adding support for DW_AT_main_subprogram in read_func_scope.

Tom> Tested on x86_64-linux with native and RFC target board readnow (
Tom> https://sourceware.org/ml/gdb-patches/2019-05/msg00073.html ).

Tom> OK for trunk?

Thank you for the patch.  This is ok.

Tom

Patch

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index b5ea9e3cc0..3e611b0842 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -13741,6 +13741,10 @@  read_func_scope (struct die_info *die, struct dwarf2_cu *cu)
   newobj->name = new_symbol (die, read_type_die (die, cu), cu,
 			     (struct symbol *) templ_func);
 
+  if (dwarf2_flag_true_p (die, DW_AT_main_subprogram, cu))
+    set_objfile_main_name (objfile, SYMBOL_LINKAGE_NAME (newobj->name),
+			   cu->language);
+
   /* If there is a location expression for DW_AT_frame_base, record
      it.  */
   attr = dwarf2_attr (die, DW_AT_frame_base, cu);