Home Original page

ld (bfd?) bug: unmatched excluded include in stabs

Mattias Engdegård mattias@virtutech.se
Mon Nov 17 18:14:00 GMT 2003 
It seems that recent binutils (at least 2.14, but not 2.13) merge
repeated include-file stabs when linking partially. When these partial
linked objects then are linked again, this can cause the generation of
excluded stabs that do not refer to any include file stab. I found
this when linking the Linux kernel.

For instance, consider the following files:

alfa.c:
 #include "alfa.h"
alfa.h:
 #include "beta.h"
 #include "gamma.h"
beta.h:
 struct A { int a; }
gamma.h:
 struct B { float b; }
gamma.c:
 #include "gamma.h"

Then gamma.o will have the stabs

  BINCL gamma.h
   LSYM (definition of B)
  EINCL

and alfa.o will contain the stabs

  BINCL alfa.h
   BINCL beta.h
    LSYM (definition of A)
   EINCL
   BINCL gamma.h
    LSYM (definition of B)
   EINCL
  EINCL

When partially linked together (-r), ld will compute checksums to BINCL stabs
and replace some BINCL/EINCL pairs by matching EXCL stabs:

  BINCL gamma.h (with a nonzero checksum)
   LSYM (definition of B)
  EINCL
  BINCL alfa.h  (with checksum == 0)
   BINCL beta.h
    LSYM (definition of A)
   EINCL
   EXCL gamma.h  (with a checksum that matches that of BINCL gamma.h)
  EINCL

The alfa.h checksum is zero, because there are no non-nested stabs there
(the EXCL stab is added afterwards).

Now consider another object file that includes alfa.h. Its stabs will be
roughly equal to those of alfa.o above. When this is linked to the partial
link, the resulting BINCL of alfa.h will have checksum != 0 (since this
time the EXCL gamma.h contributes), but the use will have checksum == 0.

Thus a debugger sees, in the final executable

  BINCL alfa.h, checksum != 0
  ...
  EXCL  alfa.h, checksum == 0

and won't be able to match them. GDB complains about this, if complaints
are turned on.

I have a testcase for this, which I could wrap up if someone is interested.
More information about the Binutils mailing list