From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9319 invoked by alias); 6 Oct 2003 14:42:51 -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 9306 invoked from network); 6 Oct 2003 14:42:47 -0000 Received: from unknown (HELO mail96.atlas.de) (194.221.176.153) by sources.redhat.com with SMTP; 6 Oct 2003 14:42:47 -0000 Received: from VSSRV01.atlas.de (vssrv01.atlas.de [10.200.101.18]) by mail96.atlas.de (Postfix) with SMTP id 4A6FB139DC for ; Mon, 6 Oct 2003 16:42:47 +0200 (CEST) Received: from mgsrv01.atlas.de ([10.200.101.16]) by VSSRV01.atlas.de (NAVGW 2.5.1.2) with SMTP id M2003100616424713622 ; Mon, 06 Oct 2003 16:42:47 +0200 Received: by mgsrv01.atlas.de (Postfix, from userid 65534) id D933922B4F; Mon, 6 Oct 2003 16:42:46 +0200 (CEST) Received: from dsit03.atlas.de (dsit03.atlas.de [141.200.35.117]) by mgsrv01.atlas.de (Postfix) with SMTP id E682022B4F; Mon, 6 Oct 2003 16:42:45 +0200 (CEST) Received: from nspc140.atlas.de by dsit03.atlas.de (5.65v4.0/1.1.10.5/28May97-0309PM) id AA23003; Mon, 6 Oct 2003 16:42:45 +0200 Message-Id: <3F818024.7020605@rheinmetall-de.com> Date: Mon, 06 Oct 2003 14:42:00 -0000 From: Roul Oldenburger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: de-de, en-us, en Mime-Version: 1.0 To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: gdb-internal: determining the type of a variable References: <3F7C1F5F.5030102@rheinmetall-de.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-7.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE, USER_AGENT_MOZILLA_UA autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-SW-Source: 2003-10/txt/msg00096.txt.bz2 Thanks for your effort giving me your explanation! Looking at the stabs information from our executables which are linked from several o-files I find FILENUM being 0 for all typedescriptions. Probably I could distinguish between the duplicate descriptions if FILNUM would differ. Unfortunately I don't know why it is 0 all the way? Roul Jim Blandy wrote: > Roul Oldenburger writes: > >>In fact the type is duration, but my problem is to distinguish between >>the different possibilities ... so looking for the typenumber alone is >>not enough. >> >>How does gdb does it?? >> >>What am I doing wrong? > > > First, have you looked at the stabs document? The manual source is in > gdb/doc/stabs.texi, and http://sources.redhat.com/gdb/documentation/ > has a link to it on-line. > > However, I don't think that's the clearest description of what's going > on. (Hmm, invest 15 minutes explaining it now, which I'll have to > repeat the next time someone asks, or days trying to improve > stabs.texi? My motto: "Fritter, fritter".) > > In general, type numbers are only going to be unique within a > compilation unit; the stabs for a given compilation unit are delimited > by N_SO stabs --- but note that there are also N_SO stabs that just > set the working directory. See the stabs document for more details. > > However, if you see an EXCL stab, then your work is harder. EXCL > stabs are produced by the linker when it factors out information > repeated in all the .o files it's linking together so it only appears > once in the executable. An EXCL stab points back to stabs earlier in > the list that also belong in this compilation unit, but have been > omitted to save space. > > The EXCL stuff depends on some trickiness with the type numbers. > Originally, stabs type numbers were just that --- numbers --- and they > were assigned sequentially. So you'd see something like: > > LSYM char:t2=r2;0;127; > ... > PSYM argv:p20=*21=*2 > > to declare argv's type as 'char **'. This meant that, if the same > header file were #included into several compilation units, its types > would be assigned whatever numbers came next in the sequence for that > compilation unit. This makes it hard to recognize whether the stabs > for two #inclusions of a file in different compilation units are > really the same or not. > > But now, type numbers are (FILENUM,TYPENUM) pairs: > > LSYM char:t(0,2)=r(0,2);0;127; > ... > PSYM argv:p(10,1)=*(10,2)=*(0,2) > > Each time we start a new source file for an #inclusion, we assign it a > new FILENUM, and start TYPENUM at one again. This means that, if the > same header file gets #included into several different compilation > units, the likelihood is that the type numbers introduced by that > header file will differ only in the file number, not the type > numbers, which makes it easier to determine whether the stabs produced > by two #inclusions of the same file in two different compilation units > are the same or not. > > The stabs introduced by a header file are bracketed by a BINCL / EINCL > pair. If the linker sees a BINCL / EINCL pair where the name of the > #included file is the same as some previous BINCL / EINCL pair, and > the stabs contained therein differ only in their file numbers, then it > replaces the second BINCL / EINCL pair and all the stabs between them > with a single EXCL stab, which points back to the first BINCL / EINCL > pair. > > Anyway, if you want to read stabs information in linked programs, not > .o files, you'll need to understand that. See dbxread.c and > stabsread.c for details. To say much more, I'd just have to refer to > them, too. -- Mit freundlichen Grüßen ^-----------------------------------------------------------+ | Rheinmetall Defence Electronics GmbH Brüggeweg 54 | | Postbox 44 84 44 | | Roul Oldenburger 28284 Bremen | | SPMU Germany | | Software Development | | | | Phone: +49 421 457 2410 | | Email: oldenburger.roul@rheinmetall-de.com | | Web: http://www.rheinmetall.com/ | | http://www.rheinmetall-de.com/ | *-----------------------------------------------------------/