This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Suggestion: Detect inconsistent structure definitions
- From: Zack Weinberg <zack at codesourcery dot com>
- To: gdb at sources dot redhat dot com
- Date: Wed, 13 Mar 2002 10:22:22 -0800
- 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