* RE: excessive stab information
@ 2005-04-28 16:48 Andy Chittenden
2005-04-28 16:53 ` Dave Korn
0 siblings, 1 reply; 30+ messages in thread
From: Andy Chittenden @ 2005-04-28 16:48 UTC (permalink / raw)
To: Dave Korn, Daniel Jacobowitz, Ian Lance Taylor; +Cc: binutils, Martin Dorey
> .... I'd have said that the
> published-interfaces
> directory "foo" should be in the default search path so that published
> interfaces are accessible everywhere; the users can #include
> "bar.h". And
> if someone wanted to create a private header file in some
> source dir called
> "bar.h", and was complaining that it would be overridden by
> the published
> "bar.h", well, that's just as much their fault as if they'd
> tried to create
> a private header file called "stdlib.h" and were complaining about the
> system's one overriding their own.
but then if you have 1000s of published directories, then the include
path becomes unwieldy and you need to change it for each new subsystem
that gets published. It also means that there's a risk of clashes if
someone's called their header file something generic - making sure that
each header file in each subsystem is uniquely named across the whole
system is unrealistic. By using a directory structure for the published
headers, we keep the compiler's include path manageable, it makes the
compiler find header files faster (ie it's not searching 1000s of
directories) and we avoid name clashes between sub-systems.
--
Andy, BlueArc Engineering
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
2005-04-28 16:48 excessive stab information Andy Chittenden
@ 2005-04-28 16:53 ` Dave Korn
0 siblings, 0 replies; 30+ messages in thread
From: Dave Korn @ 2005-04-28 16:53 UTC (permalink / raw)
To: 'Andy Chittenden', 'Daniel Jacobowitz',
'Ian Lance Taylor'
Cc: binutils, 'Martin Dorey'
----Original Message----
>From: Andy Chittenden
>Sent: 28 April 2005 17:26
>> .... I'd have said that the
>> published-interfaces
>> directory "foo" should be in the default search path so that published
>> interfaces are accessible everywhere; the users can #include "bar.h".
>> And if someone wanted to create a private header file in some
>> source dir called
>> "bar.h", and was complaining that it would be overridden by
>> the published
>> "bar.h", well, that's just as much their fault as if they'd
>> tried to create
>> a private header file called "stdlib.h" and were complaining about the
>> system's one overriding their own.
>
> but then if you have 1000s of published directories, then the include
> path becomes unwieldy and you need to change it for each new subsystem
> that gets published. It also means that there's a risk of clashes if
> someone's called their header file something generic - making sure that
> each header file in each subsystem is uniquely named across the whole
> system is unrealistic. By using a directory structure for the published
> headers, we keep the compiler's include path manageable, it makes the
> compiler find header files faster (ie it's not searching 1000s of
> directories) and we avoid name clashes between sub-systems.
Well, what would make that manageable would be if all the published
directories lived under one path, and the individual #includes then
specified #include "relative-subdir/published_foo.h". This is how most
libraries work: lib FOO publishes its header files in a subdir called FOO
under /include, and users of those libraries specify #include
"FOO/foo_interface.h". No namespace pollution, because the subdir named
after the module keeps all the different modules' interfaces separate. No
1000's of published directories in the include path, just the top-level
/include, with the include paths specified relative to that. And no
difference between how the client of a library refers to its published
interface header and how the internal components of that library do so.
Have I accounted for all your objections there?
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
@ 2005-04-29 8:13 Andy Chittenden
0 siblings, 0 replies; 30+ messages in thread
From: Andy Chittenden @ 2005-04-29 8:13 UTC (permalink / raw)
To: Dave Korn, Daniel Jacobowitz, Ian Lance Taylor; +Cc: binutils, Martin Dorey
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....
>
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
2005-04-28 16:58 Andy Chittenden
@ 2005-04-28 17:02 ` Dave Korn
0 siblings, 0 replies; 30+ messages in thread
From: Dave Korn @ 2005-04-28 17:02 UTC (permalink / raw)
To: 'Andy Chittenden', 'Daniel Jacobowitz',
'Ian Lance Taylor'
Cc: binutils, 'Martin Dorey'
----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....
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
@ 2005-04-28 16:58 Andy Chittenden
2005-04-28 17:02 ` Dave Korn
0 siblings, 1 reply; 30+ messages in thread
From: Andy Chittenden @ 2005-04-28 16:58 UTC (permalink / raw)
To: Dave Korn, Daniel Jacobowitz, Ian Lance Taylor; +Cc: binutils, Martin Dorey
that's exactly what we do!
--
Andy, BlueArc Engineering
> -----Original Message-----
> From: Dave Korn [mailto:dave.korn@artimi.com]
> Sent: 28 April 2005 17:32
> 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:26
>
> >> .... I'd have said that the
> >> published-interfaces
> >> directory "foo" should be in the default search path so
> that published
> >> interfaces are accessible everywhere; the users can
> #include "bar.h".
> >> And if someone wanted to create a private header file in some
> >> source dir called
> >> "bar.h", and was complaining that it would be overridden by
> >> the published
> >> "bar.h", well, that's just as much their fault as if they'd
> >> tried to create
> >> a private header file called "stdlib.h" and were
> complaining about the
> >> system's one overriding their own.
> >
> > but then if you have 1000s of published directories, then
> the include
> > path becomes unwieldy and you need to change it for each
> new subsystem
> > that gets published. It also means that there's a risk of clashes if
> > someone's called their header file something generic -
> making sure that
> > each header file in each subsystem is uniquely named across
> the whole
> > system is unrealistic. By using a directory structure for
> the published
> > headers, we keep the compiler's include path manageable, it
> makes the
> > compiler find header files faster (ie it's not searching 1000s of
> > directories) and we avoid name clashes between sub-systems.
>
> Well, what would make that manageable would be if all the published
> directories lived under one path, and the individual #includes then
> specified #include "relative-subdir/published_foo.h". This
> is how most
> libraries work: lib FOO publishes its header files in a
> subdir called FOO
> under /include, and users of those libraries specify #include
> "FOO/foo_interface.h". No namespace pollution, because the
> subdir named
> after the module keeps all the different modules' interfaces
> separate. No
> 1000's of published directories in the include path, just the
> top-level
> /include, with the include paths specified relative to that. And no
> difference between how the client of a library refers to its published
> interface header and how the internal components of that
> library do so.
>
> Have I accounted for all your objections there?
>
> cheers,
> DaveK
> --
> Can't think of a witty .sigline today....
>
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
2005-04-28 16:02 Andy Chittenden
@ 2005-04-28 16:32 ` Dave Korn
0 siblings, 0 replies; 30+ messages in thread
From: Dave Korn @ 2005-04-28 16:32 UTC (permalink / raw)
To: 'Andy Chittenden', 'Daniel Jacobowitz',
'Ian Lance Taylor'
Cc: binutils, 'Martin Dorey'
----Original Message----
>From: Andy Chittenden
>Sent: 28 April 2005 16:50
>> Why don't you sort out the search path in the makefile so that the
>> publishing library also finds the public interface header
>> first? That would
>> be good practice and achieve the desired consistency.
>>
>
> 'cos it doesn't work. Consider the case where we have a directory that
> publishes bar.h to foo/bar.h. In the source directory, the cpp files
> #include "bar.h". In other directories, users #include "foo/bar.h". If
> the source file was also #including a currently private header file
> "fred.h", that header file can be published later without the need to
> change existing source.
Ah, well, that's a problem. I'd have said that the published-interfaces
directory "foo" should be in the default search path so that published
interfaces are accessible everywhere; the users can #include "bar.h". And
if someone wanted to create a private header file in some source dir called
"bar.h", and was complaining that it would be overridden by the published
"bar.h", well, that's just as much their fault as if they'd tried to create
a private header file called "stdlib.h" and were complaining about the
system's one overriding their own.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
2005-04-28 15:42 Andy Chittenden
2005-04-28 15:50 ` Dave Korn
@ 2005-04-28 16:27 ` Ian Lance Taylor
1 sibling, 0 replies; 30+ messages in thread
From: Ian Lance Taylor @ 2005-04-28 16:27 UTC (permalink / raw)
To: Andy Chittenden; +Cc: Daniel Jacobowitz, Dave Korn, binutils, Martin Dorey
"Andy Chittenden" <AChittenden@bluearc.com> writes:
> > > ... Second, it seems to me that it will
> > > slow down a stabs link slightly, ...
>
> for us, it did speed it up a little!
For you, yes, because it eliminated some information, so the linker
had less data to write out. For most people, no, because it will add
some system calls and won't eliminate anything.
Ian
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
@ 2005-04-28 16:02 Andy Chittenden
2005-04-28 16:32 ` Dave Korn
0 siblings, 1 reply; 30+ messages in thread
From: Andy Chittenden @ 2005-04-28 16:02 UTC (permalink / raw)
To: Dave Korn, Daniel Jacobowitz, Ian Lance Taylor; +Cc: binutils, Martin Dorey
> Why don't you sort out the search path in the makefile so that the
> publishing library also finds the public interface header
> first? That would
> be good practice and achieve the desired consistency.
>
'cos it doesn't work. Consider the case where we have a directory that
publishes bar.h to foo/bar.h. In the source directory, the cpp files
#include "bar.h". In other directories, users #include "foo/bar.h". If
the source file was also #including a currently private header file
"fred.h", that header file can be published later without the need to
change existing source.
Your suggestion does give rise to the possibility of putting the root of
our tree in the #include path but then we don't get the benefit of
published/not published headers.
--
Andy, BlueArc Engineering
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
2005-04-28 15:42 Andy Chittenden
@ 2005-04-28 15:50 ` Dave Korn
2005-04-28 16:27 ` Ian Lance Taylor
1 sibling, 0 replies; 30+ messages in thread
From: Dave Korn @ 2005-04-28 15:50 UTC (permalink / raw)
To: 'Andy Chittenden', 'Daniel Jacobowitz',
'Ian Lance Taylor'
Cc: binutils, 'Martin Dorey'
----Original Message----
>From: Andy Chittenden
>Sent: 28 April 2005 16:34
>>> ... Most people do not refer to the same header file using two
>>> different names.
>
> This comes about as we "publish" headers that define public interfaces
> to subsystems into a "public" directory that other subsystems can
> #include from. We do this via symlinks. The "duplicate" stabs come about
> by virtue of the publishing directory finding the original header
> and the using directory using the published one.
>
> This is not the first environment in which I've seen this technique
> used.
Why don't you sort out the search path in the makefile so that the
publishing library also finds the public interface header first? That would
be good practice and achieve the desired consistency.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
@ 2005-04-28 15:42 Andy Chittenden
2005-04-28 15:50 ` Dave Korn
2005-04-28 16:27 ` Ian Lance Taylor
0 siblings, 2 replies; 30+ messages in thread
From: Andy Chittenden @ 2005-04-28 15:42 UTC (permalink / raw)
To: Daniel Jacobowitz, Ian Lance Taylor; +Cc: Dave Korn, binutils, Martin Dorey
> > ... Second, it seems to me that it will
> > slow down a stabs link slightly, ...
for us, it did speed it up a little!
> > ... Most people do not refer to the same header file using two
> > different names.
This comes about as we "publish" headers that define public interfaces
to subsystems into a "public" directory that other subsystems can
#include from. We do this via symlinks. The "duplicate" stabs come about
by virtue of the publishing directory finding the original header
and the using directory using the published one.
This is not the first environment in which I've seen this technique
used.
>
> I don't think it's a good idea even then. It assumes that
> the paths in
> stabs refer to files on the system where the linker is running.
... but that's a danger with the existing scheme without using realpath.
Given that the symbols within the BINCL would have to match exactly to
get duplicate stab suppression, I don't see that as a problem.
--
Andy, BlueArc Engineering
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
2005-04-28 15:34 ` Ian Lance Taylor
@ 2005-04-28 15:41 ` Daniel Jacobowitz
0 siblings, 0 replies; 30+ messages in thread
From: Daniel Jacobowitz @ 2005-04-28 15:41 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Andy Chittenden, Dave Korn, binutils, Martin Dorey
On Thu, Apr 28, 2005 at 11:16:46AM -0400, Ian Lance Taylor wrote:
> "Andy Chittenden" <AChittenden@bluearc.com> writes:
>
> > I've now sorted out our #includes so that no header file defines a type
> > within a #ifdef. This did save around 3% on the size of an elf so thanks
> > for that suggestion. However, we still have massive stabs. Further
> > analysis of the output of objdump --stabs led me to develop this patch
> > to bfd/stabs.c which removes a further 2%: is it ok to apply?
>
> Is it OK for you to apply? Sure, looks safe enough.
>
> Is it OK for the GNU binutils? I dunno. First, it would have to use
> lrealpath rather than realpath. Second, it seems to me that it will
> slow down a stabs link slightly, but for most people will provide no
> benefit. Most people do not refer to the same header file using two
> different names.
I don't think it's a good idea even then. It assumes that the paths in
stabs refer to files on the system where the linker is running.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
2005-04-28 15:21 Andy Chittenden
@ 2005-04-28 15:34 ` Ian Lance Taylor
2005-04-28 15:41 ` Daniel Jacobowitz
0 siblings, 1 reply; 30+ messages in thread
From: Ian Lance Taylor @ 2005-04-28 15:34 UTC (permalink / raw)
To: Andy Chittenden; +Cc: Dave Korn, binutils, Martin Dorey
"Andy Chittenden" <AChittenden@bluearc.com> writes:
> I've now sorted out our #includes so that no header file defines a type
> within a #ifdef. This did save around 3% on the size of an elf so thanks
> for that suggestion. However, we still have massive stabs. Further
> analysis of the output of objdump --stabs led me to develop this patch
> to bfd/stabs.c which removes a further 2%: is it ok to apply?
Is it OK for you to apply? Sure, looks safe enough.
Is it OK for the GNU binutils? I dunno. First, it would have to use
lrealpath rather than realpath. Second, it seems to me that it will
slow down a stabs link slightly, but for most people will provide no
benefit. Most people do not refer to the same header file using two
different names.
Ian
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
@ 2005-04-28 15:21 Andy Chittenden
2005-04-28 15:34 ` Ian Lance Taylor
0 siblings, 1 reply; 30+ messages in thread
From: Andy Chittenden @ 2005-04-28 15:21 UTC (permalink / raw)
To: Dave Korn, Ian Lance Taylor; +Cc: binutils, Martin Dorey
I've now sorted out our #includes so that no header file defines a type
within a #ifdef. This did save around 3% on the size of an elf so thanks
for that suggestion. However, we still have massive stabs. Further
analysis of the output of objdump --stabs led me to develop this patch
to bfd/stabs.c which removes a further 2%: is it ok to apply?
cvs diff: Diffing .
Index: stabs.c
===================================================================
RCS file: /cvs/src/src/bfd/stabs.c,v
retrieving revision 1.22
diff -c -w -u -r1.22 stabs.c
cvs diff: conflicting specifications of output style
--- stabs.c 11 Apr 2005 08:23:04 -0000 1.22
+++ stabs.c 28 Apr 2005 15:01:39 -0000
@@ -27,6 +27,8 @@
#include "libbfd.h"
#include "aout/stab_gnu.h"
#include "safe-ctype.h"
+#include <limits.h>
+#include <stdlib.h>
/* Stabs entries use a 12 byte format:
4 byte string table index
@@ -298,6 +300,10 @@
struct stab_link_includes_entry * incl_entry;
struct stab_link_includes_totals * t;
struct stab_excl_list * ne;
+ char resolved_path[PATH_MAX];
+
+ if (realpath(string, resolved_path) != 0)
+ string = resolved_path;
symb = symb_rover = NULL;
sum_chars = num_chars = 0;
--
Andy, BlueArc Engineering
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
2005-04-20 16:16 Andy Chittenden
@ 2005-04-20 16:24 ` Dave Korn
0 siblings, 0 replies; 30+ messages in thread
From: Dave Korn @ 2005-04-20 16:24 UTC (permalink / raw)
To: 'Andy Chittenden', 'Ian Lance Taylor'
Cc: binutils, 'Martin Dorey'
----Original Message----
>From: Andy Chittenden
>Sent: 20 April 2005 17:15
>> -----Original Message-----
>> From: Ian Lance Taylor [mailto:ian@airs.com]
>> Sent: 20 April 2005 15:59
>> In your program, always include stddef.h before sys/types.h.
> That's some global edit! We've got loads of programs all exhibiting this
> "issue". In total, there's over 15000 files that we use in various
> guises in these programs (think lots of small libraries that are linked
> together). Some of this is third party software that we have no control
> over: we could edit it but then we'd have a maintenance nightmare when
> we took a new upstream release. Oh well ...
Perhaps you can take care of this in your build system: use a string of
"-include" options on the gcc command line, to make sure that your standard
set of system headers is included right at the very start of each
compilation unit and in the same order, and allow the
multiple-include-guards to take care of any duplication in explicit #include
statements in the source.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
@ 2005-04-20 16:16 Andy Chittenden
2005-04-20 16:24 ` Dave Korn
0 siblings, 1 reply; 30+ messages in thread
From: Andy Chittenden @ 2005-04-20 16:16 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: binutils, Martin Dorey
> In your program, always include stddef.h before sys/types.h.
That's some global edit! We've got loads of programs all exhibiting this
"issue". In total, there's over 15000 files that we use in various
guises in these programs (think lots of small libraries that are linked
together). Some of this is third party software that we have no control
over: we could edit it but then we'd have a maintenance nightmare when
we took a new upstream release. Oh well ...
--
Andy, BlueArc Engineering
> -----Original Message-----
> From: Ian Lance Taylor [mailto:ian@airs.com]
> Sent: 20 April 2005 15:59
> To: Andy Chittenden
> Cc: binutils@sourceware.org; Martin Dorey
> Subject: Re: excessive stab information
>
> "Andy Chittenden" <AChittenden@bluearc.com> writes:
>
> > 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/ty
> pes.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?
>
> In your program, always include stddef.h before sys/types.h.
>
> Ian
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
2005-04-20 9:29 Andy Chittenden
@ 2005-04-20 14:59 ` Ian Lance Taylor
0 siblings, 0 replies; 30+ messages in thread
From: Ian Lance Taylor @ 2005-04-20 14:59 UTC (permalink / raw)
To: Andy Chittenden; +Cc: binutils, Martin Dorey
"Andy Chittenden" <AChittenden@bluearc.com> writes:
> 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?
In your program, always include stddef.h before sys/types.h.
Ian
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
@ 2005-04-20 9:29 Andy Chittenden
2005-04-20 14:59 ` Ian Lance Taylor
0 siblings, 1 reply; 30+ messages in thread
From: Andy Chittenden @ 2005-04-20 9:29 UTC (permalink / raw)
To: binutils; +Cc: Ian Lance Taylor, Martin Dorey
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
>
>
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
[not found] <1113927450.6799.ezmlm@sources.redhat.com>
@ 2005-04-19 16:27 ` James Cownie
0 siblings, 0 replies; 30+ messages in thread
From: James Cownie @ 2005-04-19 16:27 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: Nick Clifton, Ian Lance Taylor, Andy Chittenden, binutils, Martin Dorey
> 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
2005-04-19 13:04 ` Daniel Jacobowitz
@ 2005-04-19 14:51 ` Nick Clifton
0 siblings, 0 replies; 30+ messages in thread
From: Nick Clifton @ 2005-04-19 14:51 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: Ian Lance Taylor, Andy Chittenden, binutils, Martin Dorey
Hi Daniel,
> 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.
Oh - sorry. That does sound like an interesting optimisation.
> I believe Sun's compiler does this.
I wonder if they will release the source code... :-)
Cheers
Nick
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
2005-04-19 11:44 ` Nick Clifton
@ 2005-04-19 13:04 ` Daniel Jacobowitz
2005-04-19 14:51 ` Nick Clifton
0 siblings, 1 reply; 30+ messages in thread
From: Daniel Jacobowitz @ 2005-04-19 13:04 UTC (permalink / raw)
To: Nick Clifton; +Cc: Ian Lance Taylor, Andy Chittenden, binutils, Martin Dorey
On Tue, Apr 19, 2005 at 12:42:56PM +0100, Nick Clifton wrote:
> Hi Ian,
>
> > Ian Lance Taylor wrote:
>
> >There has been some work done on not linking debug information from
> >the object files into the executable, and having gdb fetch it from the
> >object files, but I'm not sure what the status of that is. I didn't
> >see anything in the linker docs about it.
>
> FYI: This feature is fully working. The reason it is not documented in
> the linker docs however is because it is not performed by the linker.
> It is performed by the objcopy program using the --strip-debug,
> --only-keep-debug and --add-gnu-debuglink switches. You can find out
> more about this from the binutils documentation.
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.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
2005-04-18 14:04 ` Ian Lance Taylor
@ 2005-04-19 11:44 ` Nick Clifton
2005-04-19 13:04 ` Daniel Jacobowitz
0 siblings, 1 reply; 30+ messages in thread
From: Nick Clifton @ 2005-04-19 11:44 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Andy Chittenden, binutils, Martin Dorey
Hi Ian,
> Ian Lance Taylor wrote:
> There has been some work done on not linking debug information from
> the object files into the executable, and having gdb fetch it from the
> object files, but I'm not sure what the status of that is. I didn't
> see anything in the linker docs about it.
FYI: This feature is fully working. The reason it is not documented in
the linker docs however is because it is not performed by the linker.
It is performed by the objcopy program using the --strip-debug,
--only-keep-debug and --add-gnu-debuglink switches. You can find out
more about this from the binutils documentation.
A word of caution for anyone considering using this feature however. It
is definitely known to work with GDB and DWARF (1,2 and 3) debug
information. I do not know if it has been tested with STABS debug
information however, although theoretically there is no reason why it
should not work. Also since it is making use of a GNU extension, it
probably only works with GDB, or debuggers based on GDB. (Plus of
course you need a fairly modern version of GDB in order to make use of
this feature).
Cheers
Nick
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
@ 2005-04-19 9:38 Andy Chittenden
0 siblings, 0 replies; 30+ messages in thread
From: Andy Chittenden @ 2005-04-19 9:38 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: binutils, Martin Dorey
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
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
2005-04-18 16:39 Andy Chittenden
@ 2005-04-18 17:13 ` Ian Lance Taylor
0 siblings, 0 replies; 30+ messages in thread
From: Ian Lance Taylor @ 2005-04-18 17:13 UTC (permalink / raw)
To: Andy Chittenden; +Cc: binutils, Martin Dorey
"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
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
@ 2005-04-18 16:39 Andy Chittenden
2005-04-18 17:13 ` Ian Lance Taylor
0 siblings, 1 reply; 30+ messages in thread
From: Andy Chittenden @ 2005-04-18 16:39 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: binutils, Martin Dorey
Ian
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:
first one:
896 BINCL 0 0 0000b86f 8411
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/types.h
897 BINCL 0 0 0001edcc 8475
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/types.h
898 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
899 LSYM 0 32 00000000 8540 __u_char:t(19,1)=(0,11)
900 LSYM 0 33 00000000 8564 __u_short:t(19,2)=(0,9)
901 LSYM 0 34 00000000 8588 __u_int:t(19,3)=(0,4)
902 LSYM 0 35 00000000 8610 __u_long:t(19,4)=(0,5)
903 LSYM 0 37 00000000 8633 __u_quad_t:t(19,5)=(0,7)
904 LSYM 0 38 00000000 8658 __quad_t:t(19,6)=(0,6)
905 LSYM 0 49 00000000 8681 __int8_t:t(19,7)=(0,10)
906 LSYM 0 50 00000000 8705 __uint8_t:t(19,8)=(0,11)
907 LSYM 0 51 00000000 8730 __int16_t:t(19,9)=(0,8)
908 LSYM 0 52 00000000 8754 __uint16_t:t(19,10)=(0,9)
909 LSYM 0 53 00000000 8780 __int32_t:t(19,11)=(0,1)
910 LSYM 0 54 00000000 8805 __uint32_t:t(19,12)=(0,4)
911 LSYM 0 56 00000000 8831 __int64_t:t(19,13)=(0,6)
912 LSYM 0 57 00000000 8856 __uint64_t:t(19,14)=(0,7)
913 LSYM 0 59 00000000 8882
__qaddr_t:t(19,15)=(19,16)=*(19,6)
914 LSYM 0 61 00000000 8917 __dev_t:t(19,17)=(19,5)
915 LSYM 0 62 00000000 8941 __uid_t:t(19,18)=(19,3)
916 LSYM 0 63 00000000 8965 __gid_t:t(19,19)=(19,3)
917 LSYM 0 64 00000000 8989 __ino_t:t(19,20)=(19,4)
918 LSYM 0 65 00000000 9013 __mode_t:t(19,21)=(19,3)
919 LSYM 0 66 00000000 9038 __nlink_t:t(19,22)=(19,3)
920 LSYM 0 67 00000000 9064 __off_t:t(19,23)=(0,3)
921 LSYM 0 68 00000000 9087 __loff_t:t(19,24)=(19,6)
922 LSYM 0 69 00000000 9112 __pid_t:t(19,25)=(0,1)
923 LSYM 0 70 00000000 9135 __ssize_t:t(19,26)=(0,1)
924 LSYM 0 71 00000000 9160 __rlim_t:t(19,27)=(0,3)
925 LSYM 0 72 00000000 9184 __rlim64_t:t(19,28)=(19,6)
926 LSYM 0 73 00000000 9211 __id_t:t(19,29)=(19,3)
927 LSYM 0 78 00000000 9234
__fsid_t:t(19,30)=s8__val:(19,31)=ar(0,24);0;1;(0,1),0,64;operator=::(19
,32)=#(19,30),(19,33)=&(19,30),(19,34)=*(19,30),(19,35)=&(19,36)=k(19,30
),(0,21);:_ZN8__fsid_taSERKS_;2A.;__base_ctor::(19,37)=#(19,30),(0,21),(
19,34),(19,35),(0,21);:_ZN8__fsid_tC2ERKS_;2A.;__comp_ctor::(19,37):_ZN8
__fsid_tC1ERKS_;2A.;__base_ctor::(19,38)=#(19,30),(0,21),(19,34),(0,21);
:_ZN8__fsid_tC2Ev;2A.;__comp_ctor::(19,38):_ZN8__fsid_tC1Ev;2A.;;
928 LSYM 0 81 00000000 9660 __daddr_t:t(19,39)=(0,1)
929 LSYM 0 82 00000000 9685 __caddr_t:t(19,40)=(2,24)
930 LSYM 0 83 00000000 9711 __time_t:t(19,41)=(0,3)
931 LSYM 0 84 00000000 9735 __swblk_t:t(19,42)=(0,3)
932 LSYM 0 86 00000000 9760 __clock_t:t(19,43)=(0,3)
933 LSYM 0 89 00000000 9785 __fd_mask:t(19,44)=(0,5)
934 LSYM 0 111 00000000 9810
__fd_set:t(19,45)=s128__fds_bits:(19,46)=ar(0,24);0;31;(19,44),0,1024;op
erator=::(19,47)=#(19,45),(19,48)=&(19,45),(19,49)=*(19,45),(19,50)=&(19
,51)=k(19,45),(0,21);:_ZN8__fd_setaSERKS_;2A.;__base_ctor::(19,52)=#(19,
45),(0,21),(19,49),(19,50),(0,21);:_ZN8__fd_setC2ERKS_;2A.;__comp_ctor::
(19,52):_ZN8__fd_setC1ERKS_;2A.;__base_ctor::(19,53)=#(19,45),(0,21),(19
,49),(0,21);:_ZN8__fd_setC2Ev;2A.;__comp_ctor::(19,53):_ZN8__fd_setC1Ev;
2A.;;
935 LSYM 0 114 00000000 10248 __key_t:t(19,54)=(0,1)
936 LSYM 0 117 00000000 10271 __ipc_pid_t:t(19,55)=(0,9)
937 LSYM 0 123 00000000 10298 __blkcnt_t:t(19,56)=(0,3)
938 LSYM 0 124 00000000 10324 __blkcnt64_t:t(19,57)=(19,6)
939 LSYM 0 127 00000000 10353 __fsblkcnt_t:t(19,58)=(19,4)
940 LSYM 0 128 00000000 10382
__fsblkcnt64_t:t(19,59)=(19,5)
941 LSYM 0 131 00000000 10413 __fsfilcnt_t:t(19,60)=(19,4)
942 LSYM 0 132 00000000 10442
__fsfilcnt64_t:t(19,61)=(19,5)
943 LSYM 0 135 00000000 10473 __ino64_t:t(19,62)=(19,4)
944 LSYM 0 138 00000000 10499 __off64_t:t(19,63)=(19,24)
945 LSYM 0 141 00000000 10526 __t_scalar_t:t(19,64)=(0,1)
946 LSYM 0 142 00000000 10554 __t_uscalar_t:t(19,65)=(0,4)
947 LSYM 0 145 00000000 10583 __intptr_t:t(19,66)=(0,1)
948 EINCL 0 0 00000000 0
949 LSYM 0 33 00000000 10609 u_char:t(18,1)=(19,1)
950 LSYM 0 34 00000000 10631 u_short:t(18,2)=(19,2)
951 LSYM 0 35 00000000 10654 u_int:t(18,3)=(19,3)
952 LSYM 0 36 00000000 10675 u_long:t(18,4)=(19,4)
953 LSYM 0 37 00000000 10697 quad_t:t(18,5)=(19,6)
954 LSYM 0 38 00000000 10719 u_quad_t:t(18,6)=(19,5)
955 LSYM 0 39 00000000 10743 fsid_t:t(18,7)=(19,30)
956 LSYM 0 42 00000000 10766 loff_t:t(18,8)=(19,24)
957 LSYM 0 46 00000000 10789 ino_t:t(18,9)=(19,20)
958 LSYM 0 57 00000000 10811 dev_t:t(18,10)=(19,17)
959 LSYM 0 62 00000000 10834 gid_t:t(18,11)=(19,19)
960 LSYM 0 67 00000000 10857 mode_t:t(18,12)=(19,21)
961 LSYM 0 72 00000000 10881 nlink_t:t(18,13)=(19,22)
962 LSYM 0 77 00000000 10906 uid_t:t(18,14)=(19,18)
963 LSYM 0 83 00000000 10929 off_t:t(18,15)=(19,23)
964 LSYM 0 95 00000000 10952 pid_t:t(18,16)=(19,25)
965 LSYM 0 100 00000000 10975 id_t:t(18,17)=(19,29)
966 LSYM 0 104 00000000 10997 ssize_t:t(18,18)=(19,26)
967 LSYM 0 109 00000000 11022 daddr_t:t(18,19)=(19,39)
968 LSYM 0 110 00000000 11047 caddr_t:t(18,20)=(19,40)
969 LSYM 0 114 00000000 11072 key_t:t(18,21)=(19,54)
970 BINCL 0 0 000004fd 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
971 LSYM 0 73 00000000 11154 time_t:t(21,1)=(19,41)
972 EINCL 0 0 00000000 0
973 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
974 LSYM 0 128 00000000 11177 ulong:t(18,22)=(0,5)
975 LSYM 0 129 00000000 11198 ushort:t(18,23)=(0,9)
976 LSYM 0 171 00000000 11220 int8_t:t(18,24)=(0,10)
977 LSYM 0 172 00000000 11243 int16_t:t(18,25)=(0,8)
978 LSYM 0 173 00000000 11266 int32_t:t(18,26)=(0,1)
979 LSYM 0 174 00000000 11289 int64_t:t(18,27)=(0,6)
980 LSYM 0 177 00000000 11312 u_int8_t:t(18,28)=(0,11)
981 LSYM 0 178 00000000 11337 u_int16_t:t(18,29)=(0,9)
982 LSYM 0 179 00000000 11362 u_int32_t:t(18,30)=(0,4)
983 LSYM 0 180 00000000 11387 u_int64_t:t(18,31)=(0,7)
984 LSYM 0 182 00000000 11412 register_t:t(18,32)=(0,1)
985 BINCL 0 0 00000000 11438
/home/andyc/work/octopus/headers/stdheaders/endian.h
986 BINCL 0 0 00000000 11491
/home/andyc/work/octopus/headers/stdheaders/bits/endian.h
987 BINCL 0 0 00000000 11549
/home/andyc/work/octopus/headers/stdheaders/asm-ppc/endian.h
988 EINCL 0 0 00000000 0
989 EINCL 0 0 00000000 0
990 EINCL 0 0 00000000 0
991 BINCL 0 0 00000a48 11610
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/select.h
992 BINCL 0 0 00000000 11675
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/select.h
993 EINCL 0 0 00000000 0
994 BINCL 0 0 000070e8 11741
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/sigset.h
995 LSYM 0 23 00000000 11807 __sig_atomic_t:t(28,1)=(0,1)
996 LSYM 0 31 00000000 11836
__sigset_t:t(28,2)=s128__val:(28,3)=ar(0,24);0;31;(0,5),0,1024;operator=
::(28,4)=#(28,2),(28,5)=&(28,2),(28,6)=*(28,2),(28,7)=&(28,8)=k(28,2),(0
,21);:_ZN10__sigset_taSERKS_;2A.;__base_ctor::(28,9)=#(28,2),(0,21),(28,
6),(28,7),(0,21);:_ZN10__sigset_tC2ERKS_;2A.;__comp_ctor::(28,9):_ZN10__
sigset_tC1ERKS_;2A.;__base_ctor::(28,10)=#(28,2),(0,21),(28,6),(0,21);:_
ZN10__sigset_tC2Ev;2A.;__comp_ctor::(28,10):_ZN10__sigset_tC1Ev;2A.;;
997 EINCL 0 0 00000000 0
998 BINCL 0 0 00006474 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
999 LSYM 0 86 00000000 12266
timespec:Tt(29,1)=s8tv_sec:(0,3),0,32;tv_nsec:(0,3),32,32;operator=::(29
,2)=#(29,1),(29,3)=&(29,1),(29,4)=*(29,1),(29,5)=&(29,6)=k(29,1),(0,21);
:_ZN8timespecaSERKS_;2A.;__base_ctor::(29,7)=#(29,1),(0,21),(29,4),(29,5
),(0,21);:_ZN8timespecC2ERKS_;2A.;__comp_ctor::(29,7):_ZN8timespecC1ERKS
_;2A.;__base_ctor::(29,8)=#(29,1),(0,21),(29,4),(0,21);:_ZN8timespecC2Ev
;2A.;__comp_ctor::(29,8):_ZN8timespecC1Ev;2A.;;
1000 EINCL 0 0 00000000 0
1001 LSYM 0 48 00000000 12674 fd_mask:t(26,1)=(19,44)
1002 LSYM 0 51 00000000 12698 fd_set:t(26,2)=(19,45)
1003 EINCL 0 0 00000000 0
1004 BINCL 0 0 00000000 12721
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/sysmacros.h
1005 EINCL 0 0 00000000 0
1006 LSYM 0 205 00000000 12789 blkcnt_t:t(18,33)=(19,56)
1007 LSYM 0 206 00000000 12815 fsblkcnt_t:t(18,34)=(19,58)
1008 LSYM 0 207 00000000 12843 fsfilcnt_t:t(18,35)=(19,60)
second one:
3629 BINCL 0 0 0000a45b 8411
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/types.h
3630 EXCL 0 0 0001edcc 8475
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/types.h
3631 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
3632 LSYM 0 33 00000000 700057 u_char:t(70,1)=(71,1)
3633 LSYM 0 34 00000000 700079 u_short:t(70,2)=(71,2)
3634 LSYM 0 35 00000000 700102 u_int:t(70,3)=(71,3)
3635 LSYM 0 36 00000000 700123 u_long:t(70,4)=(71,4)
3636 LSYM 0 37 00000000 700145 quad_t:t(70,5)=(71,6)
3637 LSYM 0 38 00000000 700167 u_quad_t:t(70,6)=(71,5)
3638 LSYM 0 39 00000000 700191 fsid_t:t(70,7)=(71,30)
3639 LSYM 0 42 00000000 700214 loff_t:t(70,8)=(71,24)
3640 LSYM 0 46 00000000 700237 ino_t:t(70,9)=(71,20)
3641 LSYM 0 57 00000000 700259 dev_t:t(70,10)=(71,17)
3642 LSYM 0 62 00000000 700282 gid_t:t(70,11)=(71,19)
3643 LSYM 0 67 00000000 700305 mode_t:t(70,12)=(71,21)
3644 LSYM 0 72 00000000 700329 nlink_t:t(70,13)=(71,22)
3645 LSYM 0 77 00000000 700354 uid_t:t(70,14)=(71,18)
3646 LSYM 0 83 00000000 700377 off_t:t(70,15)=(71,23)
3647 LSYM 0 95 00000000 700400 pid_t:t(70,16)=(71,25)
3648 LSYM 0 100 00000000 700423 id_t:t(70,17)=(71,29)
3649 LSYM 0 104 00000000 700445 ssize_t:t(70,18)=(71,26)
3650 LSYM 0 109 00000000 700470 daddr_t:t(70,19)=(71,39)
3651 LSYM 0 110 00000000 700495 caddr_t:t(70,20)=(71,40)
3652 LSYM 0 114 00000000 700520 key_t:t(70,21)=(71,54)
3653 EXCL 0 0 000004fd 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
3654 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
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)
3661 LSYM 0 182 00000000 700686 register_t:t(70,28)=(0,1)
3662 EXCL 0 0 00000000 11438
/home/andyc/work/octopus/headers/stdheaders/endian.h
3663 EXCL 0 0 00000000 11491
/home/andyc/work/octopus/headers/stdheaders/bits/endian.h
3664 EXCL 0 0 00000000 11549
/home/andyc/work/octopus/headers/stdheaders/asm-ppc/endian.h
3665 EXCL 0 0 00000a48 11610
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/select.h
3666 EXCL 0 0 00000000 11675
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/select.h
3667 EXCL 0 0 000070e8 11741
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/sigset.h
3668 EXCL 0 0 00006474 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
3669 EXCL 0 0 00000000 12721
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/sysmacros.h
3670 LSYM 0 205 00000000 700712 blkcnt_t:t(70,29)=(71,56)
3671 LSYM 0 206 00000000 700738 fsblkcnt_t:t(70,30)=(71,58)
3672 LSYM 0 207 00000000 700766 fsfilcnt_t:t(70,31)=(71,60)
3673 EINCL 0 0 00000000 0
third one:
3773 BINCL 0 0 0000bcb1 8411
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/types.h
3774 EXCL 0 0 0001edcc 8475
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/types.h
3775 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
3776 LSYM 0 33 00000000 703577 u_char:t(16,1)=(17,1)
3777 LSYM 0 34 00000000 703599 u_short:t(16,2)=(17,2)
3778 LSYM 0 35 00000000 703622 u_int:t(16,3)=(17,3)
3779 LSYM 0 36 00000000 703643 u_long:t(16,4)=(17,4)
3780 LSYM 0 37 00000000 703665 quad_t:t(16,5)=(17,6)
3781 LSYM 0 38 00000000 703687 u_quad_t:t(16,6)=(17,5)
3782 LSYM 0 39 00000000 703711 fsid_t:t(16,7)=(17,30)
3783 LSYM 0 42 00000000 703734 loff_t:t(16,8)=(17,24)
3784 LSYM 0 46 00000000 703757 ino_t:t(16,9)=(17,20)
3785 LSYM 0 57 00000000 703779 dev_t:t(16,10)=(17,17)
3786 LSYM 0 62 00000000 703802 gid_t:t(16,11)=(17,19)
3787 LSYM 0 67 00000000 703825 mode_t:t(16,12)=(17,21)
3788 LSYM 0 72 00000000 703849 nlink_t:t(16,13)=(17,22)
3789 LSYM 0 77 00000000 703874 uid_t:t(16,14)=(17,18)
3790 LSYM 0 83 00000000 703897 off_t:t(16,15)=(17,23)
3791 LSYM 0 95 00000000 703920 pid_t:t(16,16)=(17,25)
3792 LSYM 0 100 00000000 703943 id_t:t(16,17)=(17,29)
3793 LSYM 0 104 00000000 703965 ssize_t:t(16,18)=(17,26)
3794 LSYM 0 109 00000000 703990 daddr_t:t(16,19)=(17,39)
3795 LSYM 0 110 00000000 704015 caddr_t:t(16,20)=(17,40)
3796 LSYM 0 114 00000000 704040 key_t:t(16,21)=(17,54)
3797 EXCL 0 0 000004fd 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
3798 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
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)
3810 LSYM 0 182 00000000 704318 register_t:t(16,33)=(0,1)
3811 EXCL 0 0 00000000 11438
/home/andyc/work/octopus/headers/stdheaders/endian.h
3812 EXCL 0 0 00000000 11491
/home/andyc/work/octopus/headers/stdheaders/bits/endian.h
3813 EXCL 0 0 00000000 11549
/home/andyc/work/octopus/headers/stdheaders/asm-ppc/endian.h
3814 EXCL 0 0 00000a48 11610
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/select.h
3815 EXCL 0 0 00000000 11675
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/select.h
3816 EXCL 0 0 000070e8 11741
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/sigset.h
3817 EXCL 0 0 00006474 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
3818 EXCL 0 0 00000000 12721
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/sysmacros.h
3819 LSYM 0 205 00000000 704344 blkcnt_t:t(16,34)=(17,56)
3820 LSYM 0 206 00000000 704370 fsblkcnt_t:t(16,35)=(17,58)
3821 LSYM 0 207 00000000 704398 fsfilcnt_t:t(16,36)=(17,60)
3822 EINCL 0 0 00000000 0
fourth one:
14460 BINCL 0 0 0000a899 8411
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/types.h
14461 EXCL 0 0 0001edcc 8475
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/types.h
14462 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
14463 LSYM 0 33 00000000 1939135 u_char:t(64,1)=(65,1)
14464 LSYM 0 34 00000000 1939157 u_short:t(64,2)=(65,2)
14465 LSYM 0 35 00000000 1939180 u_int:t(64,3)=(65,3)
14466 LSYM 0 36 00000000 1939201 u_long:t(64,4)=(65,4)
14467 LSYM 0 37 00000000 1939223 quad_t:t(64,5)=(65,6)
14468 LSYM 0 38 00000000 1939245 u_quad_t:t(64,6)=(65,5)
14469 LSYM 0 39 00000000 1939269 fsid_t:t(64,7)=(65,30)
14470 LSYM 0 42 00000000 1939292 loff_t:t(64,8)=(65,24)
14471 LSYM 0 46 00000000 1939315 ino_t:t(64,9)=(65,20)
14472 LSYM 0 57 00000000 1939337 dev_t:t(64,10)=(65,17)
14473 LSYM 0 62 00000000 1939360 gid_t:t(64,11)=(65,19)
14474 LSYM 0 67 00000000 1939383 mode_t:t(64,12)=(65,21)
14475 LSYM 0 72 00000000 1939407 nlink_t:t(64,13)=(65,22)
14476 LSYM 0 77 00000000 1939432 uid_t:t(64,14)=(65,18)
14477 LSYM 0 83 00000000 1939455 off_t:t(64,15)=(65,23)
14478 LSYM 0 95 00000000 1939478 pid_t:t(64,16)=(65,25)
14479 LSYM 0 100 00000000 1939501 id_t:t(64,17)=(65,29)
14480 LSYM 0 104 00000000 1939523 ssize_t:t(64,18)=(65,26)
14481 LSYM 0 109 00000000 1939548 daddr_t:t(64,19)=(65,39)
14482 LSYM 0 110 00000000 1939573 caddr_t:t(64,20)=(65,40)
14483 LSYM 0 114 00000000 1939598 key_t:t(64,21)=(65,54)
14484 EXCL 0 0 000004fd 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
14485 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
14486 LSYM 0 128 00000000 1939621 ulong:t(64,22)=(0,5)
14487 LSYM 0 129 00000000 1939642 ushort:t(64,23)=(0,9)
14488 LSYM 0 131 00000000 1939664 uint:t(64,24)=(0,4)
14489 LSYM 0 177 00000000 1939684 u_int8_t:t(64,25)=(0,11)
14490 LSYM 0 178 00000000 1939709 u_int16_t:t(64,26)=(0,9)
14491 LSYM 0 179 00000000 1939734 u_int32_t:t(64,27)=(0,4)
14492 LSYM 0 180 00000000 1939759 u_int64_t:t(64,28)=(0,7)
14493 LSYM 0 182 00000000 1939784 register_t:t(64,29)=(0,1)
14494 EXCL 0 0 00000000 11438
/home/andyc/work/octopus/headers/stdheaders/endian.h
14495 EXCL 0 0 00000000 11491
/home/andyc/work/octopus/headers/stdheaders/bits/endian.h
14496 EXCL 0 0 00000000 11549
/home/andyc/work/octopus/headers/stdheaders/asm-ppc/endian.h
14497 EXCL 0 0 00000a48 11610
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/select.h
14498 EXCL 0 0 00000000 11675
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/select.h
14499 EXCL 0 0 000070e8 11741
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/sigset.h
14500 EXCL 0 0 00006474 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
14501 EXCL 0 0 00000000 12721
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/sysmacros.h
14502 LSYM 0 205 00000000 1939810 blkcnt_t:t(64,30)=(65,56)
14503 LSYM 0 206 00000000 1939836 fsblkcnt_t:t(64,31)=(65,58)
14504 LSYM 0 207 00000000 1939864 fsfilcnt_t:t(64,32)=(65,60)
14505 EINCL 0 0 00000000 0
fifth one:
824108 BINCL 0 0 0000bcab 8411
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/types.h
824109 BINCL 0 0 00014131 8475
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/types.h
824110 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
824111 LSYM 0 32 00000000 77829936 __u_char:t(13,1)=(0,11)
824112 LSYM 0 33 00000000 77829960 __u_short:t(13,2)=(0,9)
824113 LSYM 0 34 00000000 77829984 __u_int:t(13,3)=(0,4)
824114 LSYM 0 35 00000000 77830006 __u_long:t(13,4)=(0,5)
824115 LSYM 0 37 00000000 77830029 __u_quad_t:t(13,5)=(0,7)
824116 LSYM 0 38 00000000 77830054 __quad_t:t(13,6)=(0,6)
824117 LSYM 0 49 00000000 77830077 __int8_t:t(13,7)=(0,10)
824118 LSYM 0 50 00000000 77830101 __uint8_t:t(13,8)=(0,11)
824119 LSYM 0 51 00000000 77830126 __int16_t:t(13,9)=(0,8)
824120 LSYM 0 52 00000000 77830150 __uint16_t:t(13,10)=(0,9)
824121 LSYM 0 53 00000000 77830176 __int32_t:t(13,11)=(0,1)
824122 LSYM 0 54 00000000 77830201 __uint32_t:t(13,12)=(0,4)
824123 LSYM 0 56 00000000 77830227 __int64_t:t(13,13)=(0,6)
824124 LSYM 0 57 00000000 77830252 __uint64_t:t(13,14)=(0,7)
824125 LSYM 0 59 00000000 77830278
__qaddr_t:t(13,15)=(13,16)=*(13,6)
824126 LSYM 0 61 00000000 77830313 __dev_t:t(13,17)=(13,5)
824127 LSYM 0 62 00000000 77830337 __uid_t:t(13,18)=(13,3)
824128 LSYM 0 63 00000000 77830361 __gid_t:t(13,19)=(13,3)
824129 LSYM 0 64 00000000 77830385 __ino_t:t(13,20)=(13,4)
824130 LSYM 0 65 00000000 77830409 __mode_t:t(13,21)=(13,3)
824131 LSYM 0 66 00000000 77830434 __nlink_t:t(13,22)=(13,3)
824132 LSYM 0 67 00000000 77830460 __off_t:t(13,23)=(0,3)
824133 LSYM 0 68 00000000 77830483 __loff_t:t(13,24)=(13,6)
824134 LSYM 0 69 00000000 77830508 __pid_t:t(13,25)=(0,1)
824135 LSYM 0 70 00000000 77830531 __ssize_t:t(13,26)=(0,1)
824136 LSYM 0 71 00000000 77830556 __rlim_t:t(13,27)=(0,3)
824137 LSYM 0 72 00000000 77830580 __rlim64_t:t(13,28)=(13,6)
824138 LSYM 0 73 00000000 77830607 __id_t:t(13,29)=(13,3)
824139 LSYM 0 78 00000000 77830630
__fsid_t:t(13,30)=(13,31)=s8__val:(13,32)=ar(0,23);0;1;(0,1),0,64;;
824140 LSYM 0 81 00000000 77830698 __daddr_t:t(13,33)=(0,1)
824141 LSYM 0 82 00000000 77830723 __caddr_t:t(13,34)=(2,24)
824142 LSYM 0 83 00000000 77830749 __time_t:t(13,35)=(0,3)
824143 LSYM 0 84 00000000 77830773 __swblk_t:t(13,36)=(0,3)
824144 LSYM 0 86 00000000 77830798 __clock_t:t(13,37)=(0,3)
824145 LSYM 0 89 00000000 77830823 __fd_mask:t(13,38)=(0,5)
824146 LSYM 0 111 00000000 77830848
__fd_set:t(13,39)=(13,40)=s128__fds_bits:(13,41)=ar(0,23);0;31;(13,38),0
,1024;;
824147 LSYM 0 114 00000000 77830928 __key_t:t(13,42)=(0,1)
824148 LSYM 0 117 00000000 77830951 __ipc_pid_t:t(13,43)=(0,9)
824149 LSYM 0 123 00000000 77830978 __blkcnt_t:t(13,44)=(0,3)
824150 LSYM 0 124 00000000 77831004
__blkcnt64_t:t(13,45)=(13,6)
824151 LSYM 0 127 00000000 77831033
__fsblkcnt_t:t(13,46)=(13,4)
824152 LSYM 0 128 00000000 77831062
__fsblkcnt64_t:t(13,47)=(13,5)
824153 LSYM 0 131 00000000 77831093
__fsfilcnt_t:t(13,48)=(13,4)
824154 LSYM 0 132 00000000 77831122
__fsfilcnt64_t:t(13,49)=(13,5)
824155 LSYM 0 135 00000000 77831153 __ino64_t:t(13,50)=(13,4)
824156 LSYM 0 138 00000000 77831179 __off64_t:t(13,51)=(13,24)
824157 LSYM 0 141 00000000 77831206
__t_scalar_t:t(13,52)=(0,1)
824158 LSYM 0 142 00000000 77831234
__t_uscalar_t:t(13,53)=(0,4)
824159 LSYM 0 145 00000000 77831263 __intptr_t:t(13,54)=(0,1)
824160 EINCL 0 0 00000000 0
824161 LSYM 0 33 00000000 77831289 u_char:t(12,1)=(13,1)
824162 LSYM 0 34 00000000 77831311 u_short:t(12,2)=(13,2)
824163 LSYM 0 35 00000000 77831334 u_int:t(12,3)=(13,3)
824164 LSYM 0 36 00000000 77831355 u_long:t(12,4)=(13,4)
824165 LSYM 0 37 00000000 77831377 quad_t:t(12,5)=(13,6)
824166 LSYM 0 38 00000000 77831399 u_quad_t:t(12,6)=(13,5)
824167 LSYM 0 39 00000000 77831423 fsid_t:t(12,7)=(13,30)
824168 LSYM 0 42 00000000 77831446 loff_t:t(12,8)=(13,24)
824169 LSYM 0 46 00000000 77831469 ino_t:t(12,9)=(13,20)
824170 LSYM 0 57 00000000 77831491 dev_t:t(12,10)=(13,17)
824171 LSYM 0 62 00000000 77831514 gid_t:t(12,11)=(13,19)
824172 LSYM 0 67 00000000 77831537 mode_t:t(12,12)=(13,21)
824173 LSYM 0 72 00000000 77831561 nlink_t:t(12,13)=(13,22)
824174 LSYM 0 77 00000000 77831586 uid_t:t(12,14)=(13,18)
824175 LSYM 0 83 00000000 77831609 off_t:t(12,15)=(13,23)
824176 LSYM 0 95 00000000 77831632 pid_t:t(12,16)=(13,25)
824177 LSYM 0 100 00000000 77831655 id_t:t(12,17)=(13,29)
824178 LSYM 0 104 00000000 77831677 ssize_t:t(12,18)=(13,26)
824179 LSYM 0 109 00000000 77831702 daddr_t:t(12,19)=(13,33)
824180 LSYM 0 110 00000000 77831727 caddr_t:t(12,20)=(13,34)
824181 LSYM 0 114 00000000 77831752 key_t:t(12,21)=(13,42)
824182 BINCL 0 0 00000500 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
824183 LSYM 0 73 00000000 77831775 time_t:t(15,1)=(13,35)
824184 EINCL 0 0 00000000 0
824185 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
824186 LSYM 0 128 00000000 77831798 ulong:t(12,22)=(0,5)
824187 LSYM 0 129 00000000 77831819 ushort:t(12,23)=(0,9)
824188 LSYM 0 131 00000000 77831841 uint:t(12,24)=(0,4)
824189 LSYM 0 171 00000000 77831861 int8_t:t(12,25)=(0,10)
824190 LSYM 0 172 00000000 77831884 int16_t:t(12,26)=(0,8)
824191 LSYM 0 173 00000000 77831907 int32_t:t(12,27)=(0,1)
824192 LSYM 0 174 00000000 77831930 int64_t:t(12,28)=(0,6)
824193 LSYM 0 177 00000000 77831953 u_int8_t:t(12,29)=(0,11)
824194 LSYM 0 178 00000000 77831978 u_int16_t:t(12,30)=(0,9)
824195 LSYM 0 179 00000000 77832003 u_int32_t:t(12,31)=(0,4)
824196 LSYM 0 180 00000000 77832028 u_int64_t:t(12,32)=(0,7)
824197 LSYM 0 182 00000000 77832053 register_t:t(12,33)=(0,1)
824198 EXCL 0 0 00000000 11438
/home/andyc/work/octopus/headers/stdheaders/endian.h
824199 EXCL 0 0 00000000 11491
/home/andyc/work/octopus/headers/stdheaders/bits/endian.h
824200 EXCL 0 0 00000000 11549
/home/andyc/work/octopus/headers/stdheaders/asm-ppc/endian.h
824201 BINCL 0 0 00000a4e 11610
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/select.h
824202 EXCL 0 0 00000000 11675
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/select.h
824203 BINCL 0 0 00001846 11741
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/sigset.h
824204 LSYM 0 23 00000000 77832079
__sig_atomic_t:t(22,1)=(0,1)
824205 LSYM 0 31 00000000 77832108
__sigset_t:t(22,2)=(22,3)=s128__val:(22,4)=ar(0,23);0;31;(0,5),0,1024;;
824206 EINCL 0 0 00000000 0
824207 BINCL 0 0 00000f88 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
824208 LSYM 0 0 00000000 77832180
timespec:T(23,1)=s8tv_sec:(0,3),0,32;tv_nsec:(0,3),32,32;;
824209 EINCL 0 0 00000000 0
824210 LSYM 0 48 00000000 77832239 fd_mask:t(20,1)=(13,38)
824211 LSYM 0 51 00000000 77832263 fd_set:t(20,2)=(13,39)
824212 EINCL 0 0 00000000 0
824213 EXCL 0 0 00000000 12721
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/sysmacros.h
824214 LSYM 0 205 00000000 77832286 blkcnt_t:t(12,34)=(13,44)
824215 LSYM 0 206 00000000 77832312
fsblkcnt_t:t(12,35)=(13,46)
824216 LSYM 0 207 00000000 77832340
fsfilcnt_t:t(12,36)=(13,48)
824217 EINCL 0 0 00000000 0
sixth one:
1096827 BINCL 0 0 0000797d 8411
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/types.h
1096828 EXCL 0 0 00014131 8475
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/types.h
1096829 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
1096830 LSYM 0 42 00000000 93943389 loff_t:t(21,1)=(22,24)
1096831 LSYM 0 46 00000000 93943412 ino_t:t(21,2)=(22,20)
1096832 LSYM 0 57 00000000 93943434 dev_t:t(21,3)=(22,17)
1096833 LSYM 0 62 00000000 93943456 gid_t:t(21,4)=(22,19)
1096834 LSYM 0 67 00000000 93943478 mode_t:t(21,5)=(22,21)
1096835 LSYM 0 72 00000000 93943501 nlink_t:t(21,6)=(22,22)
1096836 LSYM 0 77 00000000 93943525 uid_t:t(21,7)=(22,18)
1096837 LSYM 0 83 00000000 93943547 off_t:t(21,8)=(22,23)
1096838 LSYM 0 95 00000000 93943569 pid_t:t(21,9)=(22,25)
1096839 LSYM 0 100 00000000 93943591 id_t:t(21,10)=(22,29)
1096840 LSYM 0 104 00000000 93943613 ssize_t:t(21,11)=(22,26)
1096841 LSYM 0 114 00000000 93943638 key_t:t(21,12)=(22,42)
1096842 EXCL 0 0 00000500 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
1096843 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
1096844 LSYM 0 128 00000000 93943661 ulong:t(21,13)=(0,5)
1096845 LSYM 0 129 00000000 93943682 ushort:t(21,14)=(0,9)
1096846 LSYM 0 131 00000000 93943704 uint:t(21,15)=(0,4)
1096847 LSYM 0 177 00000000 93943724 u_int8_t:t(21,16)=(0,11)
1096848 LSYM 0 178 00000000 93943749 u_int16_t:t(21,17)=(0,9)
1096849 LSYM 0 179 00000000 93943774 u_int32_t:t(21,18)=(0,4)
1096850 LSYM 0 180 00000000 93943799 u_int64_t:t(21,19)=(0,7)
1096851 LSYM 0 182 00000000 93943824 register_t:t(21,20)=(0,1)
1096852 LSYM 0 205 00000000 93943850 blkcnt_t:t(21,21)=(22,44)
1096853 LSYM 0 206 00000000 93943876
fsblkcnt_t:t(21,22)=(22,46)
1096854 LSYM 0 207 00000000 93943904
fsfilcnt_t:t(21,23)=(22,48)
1096855 EINCL 0 0 00000000 0
seventh and final one:
1104253 BINCL 0 0 0000948b 8411
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/types.h
1104254 EXCL 0 0 0001edcc 8475
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/types.h
1104255 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
1104256 LSYM 0 37 00000000 94102313 quad_t:t(67,1)=(68,6)
1104257 LSYM 0 38 00000000 94102335 u_quad_t:t(67,2)=(68,5)
1104258 LSYM 0 39 00000000 94102359 fsid_t:t(67,3)=(68,30)
1104259 LSYM 0 42 00000000 94102382 loff_t:t(67,4)=(68,24)
1104260 LSYM 0 46 00000000 94102405 ino_t:t(67,5)=(68,20)
1104261 LSYM 0 57 00000000 94102427 dev_t:t(67,6)=(68,17)
1104262 LSYM 0 62 00000000 94102449 gid_t:t(67,7)=(68,19)
1104263 LSYM 0 67 00000000 94102471 mode_t:t(67,8)=(68,21)
1104264 LSYM 0 72 00000000 94102494 nlink_t:t(67,9)=(68,22)
1104265 LSYM 0 77 00000000 94102518 uid_t:t(67,10)=(68,18)
1104266 LSYM 0 83 00000000 94102541 off_t:t(67,11)=(68,23)
1104267 LSYM 0 95 00000000 94102564 pid_t:t(67,12)=(68,25)
1104268 LSYM 0 100 00000000 94102587 id_t:t(67,13)=(68,29)
1104269 LSYM 0 104 00000000 94102609 ssize_t:t(67,14)=(68,26)
1104270 LSYM 0 109 00000000 94102634 daddr_t:t(67,15)=(68,39)
1104271 LSYM 0 110 00000000 94102659 caddr_t:t(67,16)=(68,40)
1104272 LSYM 0 114 00000000 94102684 key_t:t(67,17)=(68,54)
1104273 EXCL 0 0 000004fd 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
1104274 EXCL 0 0 00000000 7068
/usr/lib/gcc-lib/powerpc-eabi/3.3.3/include/stddef.h
1104275 LSYM 0 128 00000000 94102707 ulong:t(67,18)=(0,5)
1104276 LSYM 0 129 00000000 94102728 ushort:t(67,19)=(0,9)
1104277 LSYM 0 131 00000000 94102750 uint:t(67,20)=(0,4)
1104278 LSYM 0 177 00000000 94102770 u_int8_t:t(67,21)=(0,11)
1104279 LSYM 0 178 00000000 94102795 u_int16_t:t(67,22)=(0,9)
1104280 LSYM 0 179 00000000 94102820 u_int32_t:t(67,23)=(0,4)
1104281 LSYM 0 180 00000000 94102845 u_int64_t:t(67,24)=(0,7)
1104282 LSYM 0 182 00000000 94102870 register_t:t(67,25)=(0,1)
1104283 EXCL 0 0 00000000 11438
/home/andyc/work/octopus/headers/stdheaders/endian.h
1104284 EXCL 0 0 00000000 11491
/home/andyc/work/octopus/headers/stdheaders/bits/endian.h
1104285 EXCL 0 0 00000000 11549
/home/andyc/work/octopus/headers/stdheaders/asm-ppc/endian.h
1104286 EXCL 0 0 00000a48 11610
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/select.h
1104287 EXCL 0 0 00000000 11675
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/select.h
1104288 EXCL 0 0 000070e8 11741
/home/andyc/work/octopus/headers/stdheaders/bosonly/bits/sigset.h
1104289 EXCL 0 0 00006474 11095
/home/andyc/work/octopus/headers/stdheaders/bosonly/time.h
1104290 EXCL 0 0 00000000 12721
/home/andyc/work/octopus/headers/stdheaders/bosonly/sys/sysmacros.h
1104291 LSYM 0 205 00000000 94102896 blkcnt_t:t(67,26)=(68,56)
1104292 LSYM 0 206 00000000 94102922
fsblkcnt_t:t(67,27)=(68,58)
1104293 LSYM 0 207 00000000 94102950
fsfilcnt_t:t(67,28)=(68,60)
1104294 EINCL 0 0 00000000 0
--
Andy, BlueArc Engineering
*********************************************************************************
This email and any attachment is confidential. It may only be read, copied
and used by the intended recipient(s). If you are not the intended recipient (s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to: sysadmin@bluearc.com.
*********************************************************************************
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
2005-04-18 14:53 Andy Chittenden
@ 2005-04-18 15:11 ` Ian Lance Taylor
0 siblings, 0 replies; 30+ messages in thread
From: Ian Lance Taylor @ 2005-04-18 15:11 UTC (permalink / raw)
To: Andy Chittenden; +Cc: binutils, Martin Dorey
"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
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: excessive stab information
@ 2005-04-18 14:53 Andy Chittenden
2005-04-18 15:11 ` Ian Lance Taylor
0 siblings, 1 reply; 30+ messages in thread
From: Andy Chittenden @ 2005-04-18 14:53 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: binutils, Martin Dorey
Ian
Sorry about not filling in the details. We're targetting a powerpc.
objdump and gcc report:
# powerpc-eabi-objdump --version
GNU objdump 2.14.90.0.4 20030523 Debian GNU/Linux
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License. This program has absolutely no
warranty.
# powerpc-eabi-gcc -v
Reading specs from /usr/lib/gcc-lib/powerpc-eabi/3.3.3/specs
Configured with: ../src/configure -v --enable-languages=c,c++
--enable-cxx-flags=-fno-exceptions --prefix=/usr
--infodir=/usr/share/info --mandir=/usr/share/man
--with-gxx-include-dir=/usr/powerpc-eabi/include/g++
--includedir=/usr/powerpc-eabi/include/ --enable-shared --with-gnu-as
--with-gnu-ld --with-system-zlib --enable-long-long --enable-nls
--without-included-gettext --disable-checking --build=i386-linux
--host=i386-linux --target=powerpc-eabi --with-newlib
Thread model: single
gcc version 3.3.3 (Debian)
It's interesting to note what you say about using DWARF debugging: I'll
pursue that offline here to see whether we can make use of it.
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 this case, fsfilcnt_t is defined in terms of __fsfilcnt_t (again in a
single header file):
941 LSYM 0 131 00000000 10413 __fsfilcnt_t:t(19,60)=(19,4)
824153 LSYM 0 131 00000000 77831093
__fsfilcnt_t:t(13,48)=(13,4)
and that's defined in terms of __u_long (again in a single header file):
902 LSYM 0 35 00000000 8610 __u_long:t(19,4)=(0,5)
824114 LSYM 0 35 00000000 77830006 __u_long:t(13,4)=(0,5)
and finally,
680 LSYM 0 0 00000000 432 long unsigned
int:t(0,5)=r(0,5);000000000000000000000000;000000000000037777777777;
--
Andy, BlueArc Engineering
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
2005-04-18 14:26 Jan Beulich
@ 2005-04-18 14:28 ` Daniel Jacobowitz
0 siblings, 0 replies; 30+ messages in thread
From: Daniel Jacobowitz @ 2005-04-18 14:28 UTC (permalink / raw)
To: Jan Beulich; +Cc: ian, binutils
On Mon, Apr 18, 2005 at 04:26:35PM +0200, Jan Beulich wrote:
> >Finally I'll note that most people use DWARF debugging these days, not
> >stabs.
>
> Which isn't a lot better with regard to information duplication ...
True. However, -feliminate-dwarf2-dups is a bit better - still not
ideal...
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
@ 2005-04-18 14:26 Jan Beulich
2005-04-18 14:28 ` Daniel Jacobowitz
0 siblings, 1 reply; 30+ messages in thread
From: Jan Beulich @ 2005-04-18 14:26 UTC (permalink / raw)
To: ian; +Cc: binutils
>Finally I'll note that most people use DWARF debugging these days, not
>stabs.
Which isn't a lot better with regard to information duplication ...
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: excessive stab information
2005-04-18 12:44 Andy Chittenden
@ 2005-04-18 14:04 ` Ian Lance Taylor
2005-04-19 11:44 ` Nick Clifton
0 siblings, 1 reply; 30+ messages in thread
From: Ian Lance Taylor @ 2005-04-18 14:04 UTC (permalink / raw)
To: Andy Chittenden; +Cc: binutils, Martin Dorey
"Andy Chittenden" <AChittenden@bluearc.com> writes:
> Some of our executables are quite huge compared with the raw binary
> file. For example, one of our elf files is 118298855 bytes whereas the
> resulting code size is 6037476 bytes. Another is 772819419 (bin size =
> 29224584). I think the main reason that the elf files are so big is what
> looks like "duplicate" stab information: for example, I think this is
> duplicated:
>
> 1145 LSYM 0 50 00000000 40601 uint8_t:t(71,1)=(0,11)
> 1614 LSYM 0 154 00000000 261326 uint8_t:t(165,4)=(0,11)
> 3435 LSYM 0 50 00000000 567274 uint8_t:t(37,5)=(0,11)
>
> And then there are many referrers to these "different" types which
> multiply up the problem.
>
> Obviously, the above is just a small example in the maze of types that
> are used.
>
> One thing we've already done is get all compilation units to #include a
> file which uses all the plain old data types (or PODs): not only did
> this reduce the size of the elf file but it also reduced the time to
> link as, I presume, there weren't so many stabs to process - by doing
> this, we effectively "standardised" the type ids of the basic types
> (int, short etc).
>
> So, is it possible to "optimise" away these duplicate stabs? And, if so,
> where would I start looking in the binutils source?
I note that you neglected to say which platform you are on and which
version of the binutils you are using. For cases involving debugging
information, the compiler also matters, and you neglected to say which
compiler you are using.
The stabs code in the linker will already remove duplicate header
files across compilation units. This is done by looking for N_BINCL
stabs in _bfd_link_section_stabs. So the first step you should take
is to make sure that uint8_t is only defined once in a single header
file. If it is, you should get N_BINCL stabs for that header file,
and the linker should eliminate the duplicates.
If you already define uint8_t in a single header file, then this
requires further investigation to find out why the duplicate header
file elimination is not working.
In general you can't trivially optimize away duplicate stabs, without
sacrificing the ability to use gdb.
There has been some work done on not linking debug information from
the object files into the executable, and having gdb fetch it from the
object files, but I'm not sure what the status of that is. I didn't
see anything in the linker docs about it.
Finally I'll note that most people use DWARF debugging these days, not
stabs.
Ian
^ permalink raw reply [flat|nested] 30+ messages in thread
* excessive stab information
@ 2005-04-18 12:44 Andy Chittenden
2005-04-18 14:04 ` Ian Lance Taylor
0 siblings, 1 reply; 30+ messages in thread
From: Andy Chittenden @ 2005-04-18 12:44 UTC (permalink / raw)
To: binutils; +Cc: Martin Dorey
Some of our executables are quite huge compared with the raw binary
file. For example, one of our elf files is 118298855 bytes whereas the
resulting code size is 6037476 bytes. Another is 772819419 (bin size =
29224584). I think the main reason that the elf files are so big is what
looks like "duplicate" stab information: for example, I think this is
duplicated:
1145 LSYM 0 50 00000000 40601 uint8_t:t(71,1)=(0,11)
1614 LSYM 0 154 00000000 261326 uint8_t:t(165,4)=(0,11)
3435 LSYM 0 50 00000000 567274 uint8_t:t(37,5)=(0,11)
And then there are many referrers to these "different" types which
multiply up the problem.
Obviously, the above is just a small example in the maze of types that
are used.
One thing we've already done is get all compilation units to #include a
file which uses all the plain old data types (or PODs): not only did
this reduce the size of the elf file but it also reduced the time to
link as, I presume, there weren't so many stabs to process - by doing
this, we effectively "standardised" the type ids of the basic types
(int, short etc).
So, is it possible to "optimise" away these duplicate stabs? And, if so,
where would I start looking in the binutils source?
--
Andy, BlueArc Engineering
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2005-04-29 6:30 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-28 16:48 excessive stab information Andy Chittenden
2005-04-28 16:53 ` Dave Korn
-- strict thread matches above, loose matches on Subject: below --
2005-04-29 8:13 Andy Chittenden
2005-04-28 16:58 Andy Chittenden
2005-04-28 17:02 ` Dave Korn
2005-04-28 16:02 Andy Chittenden
2005-04-28 16:32 ` Dave Korn
2005-04-28 15:42 Andy Chittenden
2005-04-28 15:50 ` Dave Korn
2005-04-28 16:27 ` Ian Lance Taylor
2005-04-28 15:21 Andy Chittenden
2005-04-28 15:34 ` Ian Lance Taylor
2005-04-28 15:41 ` Daniel Jacobowitz
2005-04-20 16:16 Andy Chittenden
2005-04-20 16:24 ` Dave Korn
2005-04-20 9:29 Andy Chittenden
2005-04-20 14:59 ` Ian Lance Taylor
[not found] <1113927450.6799.ezmlm@sources.redhat.com>
2005-04-19 16:27 ` James Cownie
2005-04-19 9:38 Andy Chittenden
2005-04-18 16:39 Andy Chittenden
2005-04-18 17:13 ` Ian Lance Taylor
2005-04-18 14:53 Andy Chittenden
2005-04-18 15:11 ` Ian Lance Taylor
2005-04-18 14:26 Jan Beulich
2005-04-18 14:28 ` Daniel Jacobowitz
2005-04-18 12:44 Andy Chittenden
2005-04-18 14:04 ` Ian Lance Taylor
2005-04-19 11:44 ` Nick Clifton
2005-04-19 13:04 ` Daniel Jacobowitz
2005-04-19 14:51 ` Nick Clifton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).