Re: excessive stab information

[Ian Lance Taylor <ian at airs dot com>]

"Andy Chittenden" <AChittenden@bluearc.com> writes:

> We don't use --traditional-format. There's loads of info from the last
> BINCL up to that line in the resultant elf file. For example, here's the
> extracts of the output of objdump from the BINCL of the file that
> defines it up to the LSYM for each of those:

OK, so basically you need to look at differences between these, and
figure out where they came from.  When looking at differences, you can
ignore the first number after each left parenthesis.

I just looked at one difference.  In the list named "second one", I
see this:

> 3655   LSYM   0      128    00000000 700543 ulong:t(70,22)=(0,5)
> 3656   LSYM   0      129    00000000 700564 ushort:t(70,23)=(0,9)
> 3657   LSYM   0      177    00000000 700586 u_int8_t:t(70,24)=(0,11)
> 3658   LSYM   0      178    00000000 700611 u_int16_t:t(70,25)=(0,9)
> 3659   LSYM   0      179    00000000 700636 u_int32_t:t(70,26)=(0,4)
> 3660   LSYM   0      180    00000000 700661 u_int64_t:t(70,27)=(0,7)

In the list named "third one", I see this:

> 3799   LSYM   0      128    00000000 704063 ulong:t(16,22)=(0,5)
> 3800   LSYM   0      129    00000000 704084 ushort:t(16,23)=(0,9)
> 3801   LSYM   0      131    00000000 704106 uint:t(16,24)=(0,4)
> 3802   LSYM   0      171    00000000 704126 int8_t:t(16,25)=(0,10)
> 3803   LSYM   0      172    00000000 704149 int16_t:t(16,26)=(0,8)
> 3804   LSYM   0      173    00000000 704172 int32_t:t(16,27)=(0,1)
> 3805   LSYM   0      174    00000000 704195 int64_t:t(16,28)=(0,6)
> 3806   LSYM   0      177    00000000 704218 u_int8_t:t(16,29)=(0,11)
> 3807   LSYM   0      178    00000000 704243 u_int16_t:t(16,30)=(0,9)
> 3808   LSYM   0      179    00000000 704268 u_int32_t:t(16,31)=(0,4)
> 3809   LSYM   0      180    00000000 704293 u_int64_t:t(16,32)=(0,7)

In the latter, some typedefs for uint, int8_t, int16_t, int32_t, and
int64_t have snuck in.  Why are they only defined in the "third one"
case and not in the "second one" case?

In general header file duplicate elimination only works if the header
files are indeed duplicates.  If the header file can define different
set of types when included in different ways, then the duplication
elimination will not work.

Ian