From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14501 invoked by alias); 19 Feb 2004 21:52:25 -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 12961 invoked from network); 19 Feb 2004 21:48:52 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 19 Feb 2004 21:48:52 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 873BB1A448A; Thu, 19 Feb 2004 16:44:27 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16437.11835.435941.553479@localhost.redhat.com> Date: Thu, 19 Feb 2004 21:52:00 -0000 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/dwarf-2] Fix for the null record problem In-Reply-To: <20040219140145.GB804@gnat.com> References: <20040219140145.GB804@gnat.com> X-SW-Source: 2004-02/txt/msg00542.txt.bz2 Joel Brobecker writes: > Hello, > > This is a followup on the thread that started with: > > http://sources.redhat.com/ml/gdb-patches/2004-02/msg00058.html > > The test proposed under that thread was dropped because an empty > struct is not legal C. However, it is legal in Ada, and I've seen > a message saying that it is also legal in C++. > Let's try the Vulcan mind meld: "We need a gdb.ada directory. We need a gdb.ada directory. We need a gdb.ada directory. We need a gdb.ada directory." :-) Seriously, I'd like to see a testcase that FAIL->PASS with this patch. Can somebody get a C++ testcase, at least? the patch looks sensible, but I would like to see the testcase go in at the same time, or we'll forget. elena > I have found the source of the problem, and suggest the attached patch. > The problem was that GDB was mistakenly deducing that the empry record > was only a stub because of the lack of fields, and was therefore tagging > it with TYPE_FLAG_STUB. This is not correct. Instead, the right > approach, I believe, is to check for the DW_AT_declaration attribute. > > 2004-02-19 J. Brobecker > > * dwarf2read.c (read_structure_scope): Identify stub types > using the DW_AT_declaration attribute. > > tested on x86-linux. No regression. Fixes the testcase that was > proposed by Andrew (even though it is not legal C) and the Ada > case. > > OK to apply? > > Thanks, > -- > Joel > > PS: BTW, my past 3 months of traveling will soon be over. The past > couple of weeks have been very hectic. I have noticed that there were > some messages directed at me to which I haven't answered yet. I am > really sorry. I have kept these messages and will try to answer them > soon. > Index: dwarf2read.c > =================================================================== > RCS file: /cvs/src/src/gdb/dwarf2read.c,v > retrieving revision 1.130 > diff -u -p -r1.130 dwarf2read.c > --- dwarf2read.c 28 Jan 2004 18:43:06 -0000 1.130 > +++ dwarf2read.c 19 Feb 2004 13:58:42 -0000 > @@ -3077,6 +3077,9 @@ read_structure_scope (struct die_info *d > TYPE_LENGTH (type) = 0; > } > > + if (dwarf2_attr (die, DW_AT_declaration, cu) != NULL) > + TYPE_FLAGS (type) |= TYPE_FLAG_STUB; > + > /* We need to add the type field to the die immediately so we don't > infinitely recurse when dealing with pointers to the structure > type within the structure itself. */ > @@ -3213,11 +3216,6 @@ read_structure_scope (struct die_info *d > new_symbol (die, type, cu); > > do_cleanups (back_to); > - } > - else > - { > - /* No children, must be stub. */ > - TYPE_FLAGS (type) |= TYPE_FLAG_STUB; > } > > processing_current_prefix = previous_prefix;