This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]