From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27110 invoked by alias); 13 Mar 2002 18:40:32 -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 27054 invoked from network); 13 Mar 2002 18:40:31 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 13 Mar 2002 18:40:31 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id NAA32090; Wed, 13 Mar 2002 13:36:28 -0500 Received: from catdog (dhcpa182 [10.12.1.182]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id NAA06434; Wed, 13 Mar 2002 13:38:13 -0500 Message-ID: <106b01c1cabe$a8e520f0$b6010c0a@catdog> From: "Kris Warkentin" To: , "Zack Weinberg" References: <20020313182221.GE8197@codesourcery.com> Subject: Re: Suggestion: Detect inconsistent structure definitions Date: Wed, 13 Mar 2002 10:40:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2002-03/txt/msg00122.txt.bz2 Seems to me that the linker should be able to detect this problem as well....It uses the debug information for error reporting. The problem here is not so much the definitions of the structures but the reference to a variable defined in another object which has a different definition. Perhaps some smart checking would only look at external references and see if they have compatable definitions rather than just looking at definitions. That being said, I'd love to see that myself - we have some defines that cause things in our headers (particularily things like struct stat) to be 32 or 64 bit on some of it's fields. That can wreak some serious havoc if your lib and app are compiled with different flags. cheers, Kris ----- Original Message ----- From: "Zack Weinberg" To: Sent: Wednesday, March 13, 2002 1:22 PM Subject: Suggestion: Detect inconsistent structure definitions > Consider the following two source files: > > -- a.c -- > struct A { > int a; > int b; > }; > > struct A a = { 1, 2 }; > > -- b.c -- > struct A { > char a; > char b; > }; > > extern struct A a; > > int main(void) { > if (a.a == 1 && b.a == 2) > return 0; > else > return 1; > } > > -- > It is obvious that the complete program consisting of these two files > is buggy: the declarations of struct A do not match. However, the > program will compile, link, and execute with no complaints, just an > unexpected return value. > > When the program is large and complicated, this sort of bug can be > near-impossible to find, especially when the structure type > declaration _is_ properly isolated in a header file, but other headers > (possibly from third-party libraries) have issued inconsistent > typedefs/#defines for the aggregate's member types. I just spent two > days chasing exactly this problem in an INN installation. > > The compiler and linker do not have enough information to detect the > bug, but gdb does; each object file's debug info will contain a type > declaration for struct A, and they won't match. With stabs, it's > obvious just doing > > $ strings -a a.out | grep '^A:' > A:T(0,20)=s8a:(0,1),0,32;b:(0,1),32,32;; > A:T(0,20)=s2a:(0,2),0,8;b:(0,2),8,8;; > > I can see the same thing in readelf -w output when DWARF2 is used, > although more verbosely. > > It Would Be Nice if gdb would notice this and print a warning message, > along the lines of > > warning: type `struct A' defined inconsistently in object files `a.o' > and `b.o' > > when started up. > > zw >