From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8492 invoked by alias); 2 Oct 2003 15:40:09 -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 8470 invoked from network); 2 Oct 2003 15:40:08 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 2 Oct 2003 15:40:08 -0000 Received: by zenia.home (Postfix, from userid 5433) id 5F21D20766; Thu, 2 Oct 2003 10:35:38 -0500 (EST) To: Roul Oldenburger Cc: gdb@sources.redhat.com Subject: Re: gdb-internal: determining the type of a variable References: <3F7C1F5F.5030102@rheinmetall-de.com> From: Jim Blandy Date: Thu, 02 Oct 2003 15:40:00 -0000 In-Reply-To: <3F7C1F5F.5030102@rheinmetall-de.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00060.txt.bz2 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.