Message ID | 20190505102520.GA5031@delia |
---|---|
State | New, archived |
Headers |
Received: (qmail 53079 invoked by alias); 5 May 2019 10:25:28 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 53070 invoked by uid 89); 5 May 2019 10:25:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_STOCKGEN, SPF_PASS autolearn=ham version=3.3.1 spammy=sk:dw_at_m, sk:DW_AT_m, dwarf2_cu, objfile X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 05 May 2019 10:25:27 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E71CEAC2C; Sun, 5 May 2019 10:25:24 +0000 (UTC) Date: Sun, 5 May 2019 12:25:22 +0200 From: Tom de Vries <tdevries@suse.de> To: gdb-patches@sourceware.org Cc: Tom Tromey <tom@tromey.com> Subject: [PATCH][gdb/symtab] Support DW_AT_main_subprogram with -readnow. Message-ID: <20190505102520.GA5031@delia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes |
Commit Message
Tom de Vries
May 5, 2019, 10:25 a.m. UTC
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(+)
Comments
[ 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
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
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
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" == 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
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);