RE: excessive stab information

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

true: if all directories published their headers in a consistent manner,
that wouldn't be too difficult as our makerules do know the path
relative to the root of our tree. Unfortunately they don't but that can
be changed. Thanks for the suggestion.

Unfortunately, this'll only save around 2% on the size of the file
though. However, I think we've found another reason for the gross size
of the stabs in our elfs but we think that's the fault of the compiler.
It seems that in some circumstances involving C++ templates, it decides
to throw in arbitrary templated types into a BINCL even when names in
those types bear no relation to the types being used in the header file
in question. We're now going to investigate that route (FWIW we're using
gcc 3.3.3).

-- 
Andy, BlueArc Engineering
 

> -----Original Message-----
> From: Dave Korn [mailto:dave.korn@artimi.com] 
> Sent: 28 April 2005 17:53
> To: Andy Chittenden; 'Daniel Jacobowitz'; 'Ian Lance Taylor'
> Cc: binutils@sourceware.org; Martin Dorey
> Subject: RE: excessive stab information
> 
> ----Original Message----
> >From: Andy Chittenden
> >Sent: 28 April 2005 17:48
> 
> > that's exactly what we do!
> 
>   With the exception of specifying the 
> top-level-include-dir-relative path
> to the published header when it's being included by a source 
> file in the
> same library, because that's why you're ending up with 
> different paths.
> 
>   Hmm.  So perhaps if every compile always has -I include/, 
> so that #include
> "module/header.h" will work anywhere, and when compiling 
> module XXX, you
> specify "-I include/XXX -I include/" in that order, so that 
> in module XXX a
> #include of "header.h" will match include/XXX/header.h before 
> it matches
> ./header.h ?
> 
>   There has to be a way to make this work nicely!
>  
>     cheers,
>       DaveK
> -- 
> Can't think of a witty .sigline today....
> 
>