From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104244 invoked by alias); 30 May 2018 20:55:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 104233 invoked by uid 89); 30 May 2018 20:55:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 May 2018 20:55:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 48E70560B5; Wed, 30 May 2018 16:55:50 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DxnscrwkuMck; Wed, 30 May 2018 16:55:50 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 132E756098; Wed, 30 May 2018 16:55:50 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 4653883056; Wed, 30 May 2018 13:55:48 -0700 (PDT) Date: Wed, 30 May 2018 22:26:00 -0000 From: Joel Brobecker To: Keith Seitz Cc: Tom Tromey , Sergio Durigan Junior , gdb-patches@sourceware.org, Pedro Alves Subject: Re: possible fix for PR symtab/23010 Message-ID: <20180530205548.nump2kfxfsxuwfhc@adacore.com> References: <87po34kzxh.fsf@tromey.com> <20180430224454.wrnu4u45o5gukrxs@adacore.com> <20180507171309.f4yjprji4g3deubw@adacore.com> <8736yp4xo8.fsf@redhat.com> <87po1l2ab0.fsf@tromey.com> <87d0xl7ulv.fsf@redhat.com> <87lgc91yrf.fsf@tromey.com> <8f477b41-06ba-63a7-716b-0f2f7303da37@redhat.com> <2c888612-11e8-b376-5797-b40fada46867@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2c888612-11e8-b376-5797-b40fada46867@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-05/txt/msg00820.txt.bz2 > [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