From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1836 invoked by alias); 13 Mar 2002 18:22:24 -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 1760 invoked from network); 13 Mar 2002 18:22:21 -0000 Received: from unknown (HELO taltos.codesourcery.com) (66.92.14.122) by sources.redhat.com with SMTP; 13 Mar 2002 18:22:21 -0000 Received: from zack by taltos.codesourcery.com with local (Exim 3.35 #1 (Debian)) id 16lDOI-0006Vp-00 for ; Wed, 13 Mar 2002 10:22:22 -0800 Date: Wed, 13 Mar 2002 10:22:00 -0000 To: gdb@sources.redhat.com Subject: Suggestion: Detect inconsistent structure definitions Message-ID: <20020313182221.GE8197@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i From: Zack Weinberg X-SW-Source: 2002-03/txt/msg00121.txt.bz2 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