From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30206 invoked by alias); 15 Apr 2004 22:22:18 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30193 invoked from network); 15 Apr 2004 22:22:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 15 Apr 2004 22:22:16 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3FMMGJW032726 for ; Thu, 15 Apr 2004 18:22:16 -0400 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3FMMFj11833; Thu, 15 Apr 2004 18:22:15 -0400 To: Jason Merrill Cc: gdb-patches@sources.redhat.com Subject: Re: DW_AT_specification: long ago GDB change References: From: Jim Blandy In-Reply-To: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Date: Thu, 15 Apr 2004 22:22:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-04/txt/msg00332.txt.bz2 Jason Merrill writes: > On 15 Apr 2004 00:17:23 -0500, Jim Blandy wrote: > > > Back in 1999, you posted this patch: > > > > http://sources.redhat.com/ml/gdb-patches/1999-q4/msg00325.html > > > > Do you know why you tested for the presence of DW_AT_specification, as > > well as DW_AT_declaration? > > > > I can't think of a case where a die would be a declaration, but also > > refer to a specification; since DW_AT_specification generally points > > from definitions to previous declarations, I'd rather expect > > specifications to point at declarations. And even if a declaration > > did have a specification, it would still be a declaration. > > Yes. IIRC, the issue is that dwarf_attr looks through the > DW_AT_specification link, so it will find a DW_AT_declaration attribute in > the definition. Also looking for DW_AT_specification allows us to avoid > that false positive for the test. You're right. Eeeew. It's clearly wrong to follow DW_AT_specification and return the value of the specification's DW_AT_declaration attribute. For most attributes, though, that's the right behavior. Here are the attributes I see that we shouldn't search for in dies referenced by DW_AT_specification, but which are reasonable to look for in dies referred to by DW_AT_abstract_origin: - DW_AT_declaration - DW_AT_decl_column - DW_AT_decl_file - DW_AT_decl_line Here are attributes which apply only to a specific die, and should never be searched for on any referenced DIE: - DW_AT_sibling I don't think that needs to be addressed; it's only relevant when reading dies anyway. I'll try to put together a patch for this.