RE: excessive stab information

["Andy Chittenden" <AChittenden at bluearc dot com>]

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
>