From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13233 invoked by alias); 4 Jan 2002 19:45:13 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13173 invoked from network); 4 Jan 2002 19:45:08 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 4 Jan 2002 19:45:08 -0000 Received: from rtl.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA03343; Fri, 4 Jan 2002 11:45:05 -0800 (PST) Received: (from ezannoni@localhost) by rtl.cygnus.com (8.11.2/8.11.0) id g04IvsC07394; Fri, 4 Jan 2002 13:57:54 -0500 X-Authentication-Warning: localhost.localdomain: ezannoni set sender to ezannoni@cygnus.com using -f From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15413.64306.693267.391667@localhost.localdomain> Date: Fri, 04 Jan 2002 11:45:00 -0000 To: "debashis mahata" Cc: Subject: Re: Double ';' problem in stabs In-Reply-To: <001601c18f83$e123ebc0$73b17fc0@8420044-mahatad.wipro.com> References: <001601c18f83$e123ebc0$73b17fc0@8420044-mahatad.wipro.com> X-Mailer: VM 7.00 under Emacs 20.7.1 X-SW-Source: 2002-01/txt/msg00011.txt.bz2 Debashis, I have committed the suggested fix. http://sources.redhat.com/ml/gdb-patches/2002-01/msg00035.html Thanks Elena debashis mahata writes: > Hi all, > > This problem was observed while using Gdb on code that is > compiled with Sun C Compiler Forte 6 update 2.( cc - 5.3) > > While going through the Gdb code, I have noticed one issue > in handling stabs for a structure / union, looks like some > assumptions has been made about the format, which is not > documented. The assumption made is - the structure or union > stabs should end with two consecutive semicolon i.e. ';;'. > > One example (using Sun compiler) - For the structure > struct node{ > int I; > char C; > }; > the generated stab is - "node:T(0,21)=s8I:(0,3),0,32;C:(0,1),32,8;;" > where, > $cc -V > cc: WorkShop Compilers 5.0 98/12/15 C 5.0 > > You can see that the stab has two consecutive ';' at the > end. But the last ';' is not documented in Sun stab document. > Neither the Gdb stab document says that the last ';' should be > present. The code is in file stabsread.c (function: > read_struct_fields()), where Gdb searches for the last ';'. > The corresponding code is - > > /* Read each data member type until we find the terminating ';' at the > end > of > the data member list, or break for some other reason such as > finding > the > start of the member function list. */ > > while (**pp != ';') > { > ..... > > Some compilers does not generates the last ';'. For the > above mentioned example and using the > $cc -V > cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15 > > compiler the generated stab is - > "node:T(0,21)=s8I:(0,3),0,32;C:(0,1),32,8;" > > In this example the last ';'is missing. > > Questions: > 1. Is it anywhere documented that the last ';' (the second one) should > be present? > 2. If not, is it a bug (the assumption that last ';' should > be persent) in Gdb, which requires a fix? > 3. In case a fix is required what will be the long term strategy? > > Thanks in advance, > debashis > ------------------------------------------------------------------------------------------------------------------------- > Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and > is intended for use only by the individual or entity to which it is > addressed, and may contain information that is privileged, confidential or > exempt from disclosure under applicable law. If you are not the intended > recipient or it appears that this mail has been forwarded to you without > proper authority, you are notified that any use or dissemination of this > information in any manner is strictly prohibited. In such cases, please > notify us immediately at mailto:mailadmin@wipro.com and delete this mail > from your records. > ----------------------------------------------------------------------------------------------------------------------