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:
> I happened to pick on uint8_t as that was a fairly simple example: as it
> happens uint8_t is defined by more than one header file so maybe that
> wasn't such a good example. Another more complex case is fsfilcnt_t
> which is defined in a single header file:
>
> 1008 LSYM 0 207 00000000 12843 fsfilcnt_t:t(18,35)=(19,60)
> 3672 LSYM 0 207 00000000 700766 fsfilcnt_t:t(70,31)=(71,60)
> 3821 LSYM 0 207 00000000 704398 fsfilcnt_t:t(16,36)=(17,60)
> 14504 LSYM 0 207 00000000 1939864 fsfilcnt_t:t(64,32)=(65,60)
> 824216 LSYM 0 207 00000000 77832340
> fsfilcnt_t:t(12,36)=(13,48)
> 1096854 LSYM 0 207 00000000 93943904
> fsfilcnt_t:t(21,23)=(22,48)
> 1104293 LSYM 0 207 00000000 94102950
> fsfilcnt_t:t(67,28)=(68,60)
In the various .o files which define fsfilcnt_t, do you see N_BINCL
stabs describing the header file which defines the type? When
comparing two different .o files which define fsfilcnt_t, such that
the duplicate is not eliminated in the final output, what is the
sequence of stabs you see in between the N_BINCL and the N_EINCL?
And just to check the obvious, I assume that you aren't using the
linker option --traditional-format.
Ian