This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: excessive stab information
- From: "Andy Chittenden" <AChittenden at bluearc dot com>
- To: "Ian Lance Taylor" <ian at airs dot com>
- Cc: <binutils at sourceware dot org>,"Martin Dorey" <mdorey at bluearc dot com>
- Date: Tue, 19 Apr 2005 10:38:15 +0100
- Subject: RE: excessive stab information
thanks for the suggestions. We'll certainly look at streamlining those
"system" header files.
FWIW I tried using dwarf-2 instead of stabs but:
o the .o files are bigger - don't really care about this
if performance of ld was quicker
o even a very simple link is taking ages (over 22 minutes
and counting) whereas it took around 28 seconds for
a stabs based link to complete whilst that was going on.
(this is on a AMD 64 3500+ processor) and it failed to
link with loads of errors like this:
/home/andyc/tmp/newwork/nelson/lib/ppc_BOS-eabi_debug/ethernet-gt6426x-i
nit.relf(.debug_info+0x37a01): In function `DW.types.h.086761d8.40':
: multiple definition of `DW.types.h.086761d8.40'
/home/andyc/tmp/newwork/nelson/lib/ppc_BOS-eabi_debug/arp.relf(.debug_in
fo+0x449a4): first defined here
I presume these are dwarf related.
--
Andy, BlueArc Engineering
> -----Original Message-----
> From: Ian Lance Taylor [mailto:ian@airs.com]
> Sent: 18 April 2005 18:13
> To: Andy Chittenden
> Cc: binutils@sourceware.org; Martin Dorey
> Subject: 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
>