Problems with ld and EXCL symbols in STABS

[Stig Petter Olsroed]

Hi!

I think I have found a design weakness in the implementation of the
EXCL stabs-symbol used to reduce the amount of debug information.

Versions of ld checked: 2.8, 2.9.1, 2.11 (Solaris 2.6)
Versions of gdb checked: 4.18, 5.0       (Solaris 2.6) 

The compiler used to compile version binutils-2.11 and gdb-5.0 is
gcc-2.95.2 (only stated for completenes since this is a bug in the
algorithm and not in the generated code!).

I have recreated the problem found in a rather large program with a
small comprehensible example program. It consistes of two modules,
main.c and mod1.c, and some include files, common.h, uncommon.h,
inc1.h and inc2.h. They are compiled using gcc-2.95.2 that produces
stabs debug information with BINCL symbols for include files. This
will cause the linker (ld) to produce EXCL symbols for the BINCL/EINCL
pairs it thinks are equal. 

The problem occurs since the comparison is done without including the
file sequence numbers. This is OK for the file sequence numbers for
the BINCL file, but will break external references.

As you can see from the stabs extracts below (found in the tar-ball
attached at the end of the mail), the BINCL/EINCL pairs in mod1.o
has been converted to EXCL. This will however result in the 
external reference to (2,1) at line 30 and 33 in Sample C to be
converted to a reference to (1,1) at line 26 and 29 in Sample A.
In Sample B this refernce is to s_tag a structur. It should have been
to MYINT, which in mod1 is 'unsigned short'. 

This brings us on to the second problem. The way gdb solves this
design flaw is to just take all types read from a BINCL/EINCL pair
as the types to use in place of an EXCL. This is also a problem since
the type in mod1.o would be turned into 'unsigned long'! 

---------------------------------------------------------------------

Sample A) Stabs from main.o          (from test_gld_error.stab)
 
22     BINCL  0      0      000003dc 867    common.h
23     LSYM   0      7      00000000 876    MYINT:t(1,1)=(0,5)
24     EINCL  0      0      00000000 895    
25     BINCL  0      0      00000605 896    inc2.h
26     LSYM   0      4      00000000 903    inc2_type1:t(2,1)=(1,1)
27     EINCL  0      0      00000000 895    
28     BINCL  0      0      00000604 927    inc1.h
29     LSYM   0      4      00000000 934    inc1_type1:t(3,1)=(1,1)
30     EINCL  0      0      00000000 895    

Samble B) Stabs from mod1.o          (from test_gld_error.stabs)
67     BINCL  0      0      0000102f 993    uncommon.h
68     LSYM   0      0      00000000 1004   
s_tag:T(1,1)=s8key:(0,1),0,32;next:(1,2)=*(1,1),32,32;;
69     LSYM   0      7      00000000 1060   S_T:t(1,3)=(1,1)
70     EINCL  0      0      00000000 895    
71     BINCL  0      0      000003e0 867    common.h
72     LSYM   0      5      00000000 1077   MYINT:t(2,1)=(0,9)
73     EINCL  0      0      00000000 895    
74     EXCL   0      0      00000604 927    inc1.h
75     EXCL   0      0      00000605 896    inc2.h

Samble C) Original stabs from mod1.o (from mod1.o.stabs)

22     BINCL  0      0      00000000 875    uncommon.h
23     LSYM   0      0      00000000 886    
s_tag:T(1,1)=s8key:(0,1),0,32;next:(1,2)=*(1,1),32,32;;
24     LSYM   0      7      00000000 942    S_T:t(1,3)=(1,1)
25     EINCL  0      0      00000000 0      
26     BINCL  0      0      00000000 959    common.h
27     LSYM   0      5      00000000 968    MYINT:t(2,1)=(0,9)
28     EINCL  0      0      00000000 0      
29     BINCL  0      0      00000000 987    inc1.h
30     LSYM   0      4      00000000 994    inc1_type1:t(3,1)=(2,1)
31     EINCL  0      0      00000000 0      
32     BINCL  0      0      00000000 1018   inc2.h
33     LSYM   0      4      00000000 1025   inc2_type1:t(4,1)=(2,1)
34     EINCL  0      0      00000000 0      

-------------------------------------------------------------------------

The problems above can be illustrated with gdb as follows:

% gdb test_gld_error;
This GDB was configured as "sparc-sun-solaris2.6"...
(gdb) b main
Breakpoint 1 at 0x1053c: file main.c, line 10.
(gdb) b f1
Breakpoint 2 at 0x10584: file mod1.c, line 12.
(gdb) r
Starting program: /.../excl/test_gld_error 

Breakpoint 1, main () at main.c:10
10        b =  100;
(gdb) ptype b
type = long unsigned int
(gdb) c
Continuing.

Breakpoint 2, f1 () at mod1.c:12
12        b =  100;
(gdb) ptype b                              *********************
type = long unsigned int                     <==== Wrong type!!*
                                           *********************

-------------------------------------------------------------------------


As opposed to a run from a program compiled with gcc-2.7.2.1 (without
EXCL)

This GDB was configured as "sparc-sun-solaris2.6"...
(gdb) b main
Breakpoint 1 at 0x1045c: file main.c, line 10.
(gdb) b f1
Breakpoint 2 at 0x104a4: file mod1.c, line 12.
(gdb) r
Starting program: /users/stigp/src2/excl/test_gld_error 

Breakpoint 1, main () at main.c:10
10        b =  100;
(gdb) ptype b 
type = long unsigned int
(gdb) c 
Continuing.

Breakpoint 2, f1 () at mod1.c:12
12        b =  100;
(gdb) ptype b                            ********************
type = short unsigned int                 <==== Correct type*
                                         ********************

--------------------------------------------------------------------

The tar-ball also includes an example (test_gdb_error) that, by
chance, is correct as far as EXCL goes, but still get the same gdb 
type bug! 

A patch for bfd/stabs.c that would make the problem less likely to
occur is included in the tar-ball. I don't know if you have
investigated the likelyhood of a checksum collisions, but I do not
think it is enough for a 100% certain match and could break the STABS
output in some cases!  

Have you considered makeing an option to turn off EXCL generation?

Regards,
Stig Petter Olsroed

Find attached below a tar-ball with a set of files that will reproduce
the problem.