excessive stab information

[Andy Chittenden]

So I've started to rationalise some header files so that there are no
conditionally compiled chunks of header files as this should make the
optimisation of stabs work properly. However, one of the culprits is
sys/types.h that is supposed to define size_t
<http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html
>. However, size_t is defined by the gcc supplied header file stddef.h.
One way to deal with this is to #define __need_size_t and #include
<stddef.h> and get the conditional compilation wizardry in that file to
deal with it. However, that in its own right is going to cause
"duplicate" stabs if another compilation unit #includes stddef.h in its
entirety. If another header file references size_t, then depending on
how size_t got defined in a particular compilation unit, then a whole
header file's worth of definition is going to be "duplicated".

Has anyone got any suggestions as to how to prevent this?

-- 
Andy, BlueArc Engineering
 

> -----Original Message-----
> From: James Cownie [mailto:jcownie@etnus.com] 
> Sent: 19 April 2005 17:27
> To: Daniel Jacobowitz
> Cc: Nick Clifton; Ian Lance Taylor; Andy Chittenden; 
> binutils@sourceware.org; Martin Dorey
> Subject: Re: excessive stab information
> 
> 
> > That's not quite the same thing; this links debug 
> information into the
> > executable, then copies it elsewhere.  Ian's describing an 
> approach of
> > leaving the debug info in unlinked object files and then 
> referencing it
> > from the executable - never including it at all.
> > 
> > I believe Sun's compiler does this.
> 
> Sun do it with Stabs (see the .stabs.index section and related
> documentation). 
> 
> HP do it on HPUX with DWARF (which requires some additional 
> linker magic
> and sections to allow you to work out which object file any 
> chunk of any
> output section came from).
> 
> -- 
> -- Jim
> --
> James Cownie	<jcownie@etnus.com>
> Etnus, LLC.     +44 117 9071438
> http://www.etnus.com
> 
> 
>