This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: excessive stab information
"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