I have been looking at object files to see if I can reduce the memory usage for minimum systems. There are two things I have noticed:

1. In the data segment there is some source code as ascii text from a template in gcc/atomics.d . This is in the actual data segment and not in debug info segments and goes into the data segment of the executable. I do not see any code using this data. Why is this in the executable and is it possible to remove it?

2. In the data segment there is also __init for all types. I assume that they contain the initial values that are copied when a new object of this type is created. Is this data mutable and should it really be in data segment and not in rodata?

Am Thu, 14 Aug 2014 10:07:04 +0000
schrieb "Timo Sintonen" <t.sintonen@luukku.com>:

> I have been looking at object files to see if I can reduce the memory usage for minimum systems. There are two things I have noticed:
> 
> 1. In the data segment there is some source code as ascii text from a template in gcc/atomics.d . This is in the actual data segment and not in debug info segments and goes into the data segment of the executable. I do not see any code using this data. Why is this in the executable and is it possible to remove it?
> 

Strange, could you post a testcase?

> 2. In the data segment there is also __init for all types. I assume that they contain the initial values that are copied when a new object of this type is created.

Correct, it's for '.init' (there's especially __..._TypeInfo_init which is the initializer for typeinfo. I've implemented -fno-rtti in a private git branch to get rid of typeinfo)

> Is this data mutable and should it really be in data segment and not in rodata?
> 

I think it should be in rodata.

On Thursday, 14 August 2014 at 17:13:23 UTC, Johannes Pfau wrote:
> Am Thu, 14 Aug 2014 10:07:04 +0000
> schrieb "Timo Sintonen" <t.sintonen@luukku.com>:
>
>> I have been looking at object files to see if I can reduce the memory usage for minimum systems. There are two things I have noticed:
>> 
>> 1. In the data segment there is some source code as ascii text from a template in gcc/atomics.d . This is in the actual data segment and not in debug info segments and goes into the data segment of the executable. I do not see any code using this data. Why is this in the executable and is it possible to remove it?
>> 
>
> Strange, could you post a testcase?
It seems this comes from libdruntime and it exists in object.o and core/atomic.o, Testcase is to compile minlibd library as it is currently in the repo using the makefile as such.
But I think it will be in any object file that imports gcc.atomics and uses the template in there.

>
>> 2. In the data segment there is also __init for all types. I assume that they contain the initial values that are copied when a new object of this type is created.
>
> Correct, it's for '.init' (there's especially __..._TypeInfo_init which
> is the initializer for typeinfo. I've implemented -fno-rtti in a private
> git branch to get rid of typeinfo)
>
>> Is this data mutable and should it really be in data segment and not in rodata?
>> 
>
> I think it should be in rodata.

So it is not a bug and not a feature. It is just because it does not matter? Maybe a feature request?

On 08/14/14 19:53, Timo Sintonen via D.gnu wrote:
> On Thursday, 14 August 2014 at 17:13:23 UTC, Johannes Pfau wrote:
>> Am Thu, 14 Aug 2014 10:07:04 +0000
>> schrieb "Timo Sintonen" <t.sintonen@luukku.com>:
>>
>>> I have been looking at object files to see if I can reduce the memory usage for minimum systems. There are two things I have noticed:
>>>
>>> 1. In the data segment there is some source code as ascii text from a template in gcc/atomics.d . This is in the actual data segment and not in debug info segments and goes into the data segment of the executable. I do not see any code using this data. Why is this in the executable and is it possible to remove it?
>>>
>>
>> Strange, could you post a testcase?
> It seems this comes from libdruntime and it exists in object.o and core/atomic.o, Testcase is to compile minlibd library as it is currently in the repo using the makefile as such.
> But I think it will be in any object file that imports gcc.atomics and uses the template in there.

diff --git a/libphobos/libdruntime/gcc/atomics.d b/libphobos/libdruntime/gcc/atomics.d index 78e644191e8f..ee1a146b680e 100644
--- a/libphobos/libdruntime/gcc/atomics.d
+++ b/libphobos/libdruntime/gcc/atomics.d
@@ -28,7 +28,7 @@ import gcc.builtins;
  */
 private template __sync_op_and(string op1, string op2)
 {
-    const __sync_op_and = `
+    enum __sync_op_and = `
 T __sync_` ~ op1 ~ `_and_` ~ op2 ~ `(T)(const ref shared T ptr, T value)
 {
     static if (T.sizeof == byte.sizeof)

artur

Am Thu, 14 Aug 2014 17:53:32 +0000
schrieb "Timo Sintonen" <t.sintonen@luukku.com>:

> On Thursday, 14 August 2014 at 17:13:23 UTC, Johannes Pfau wrote:
> > Am Thu, 14 Aug 2014 10:07:04 +0000
> > schrieb "Timo Sintonen" <t.sintonen@luukku.com>:
> >
> >> I have been looking at object files to see if I can reduce the memory usage for minimum systems. There are two things I have noticed:
> >> 
> >> 1. In the data segment there is some source code as ascii text from a template in gcc/atomics.d . This is in the actual data segment and not in debug info segments and goes into the data segment of the executable. I do not see any code using this data. Why is this in the executable and is it possible to remove it?
> >> 
> >
> > Strange, could you post a testcase?
> It seems this comes from libdruntime and it exists in object.o
> and core/atomic.o, Testcase is to compile minlibd library as it
> is currently in the repo using the makefile as such.
> But I think it will be in any object file that imports
> gcc.atomics and uses the template in there.
> 

If you're referring to this: http://dpaste.dzfl.pl/fe75e8c7dfca

This seems to be the const variable in __sync_op_and. Try to change the code to "immutable __sync_op_and = " or "enum __sync_op_and = " and file a bug report.

> >
> >> 2. In the data segment there is also __init for all types. I assume that they contain the initial values that are copied when a new object of this type is created.
> >
> > Correct, it's for '.init' (there's especially
> > __..._TypeInfo_init which
> > is the initializer for typeinfo. I've implemented -fno-rtti in
> > a private
> > git branch to get rid of typeinfo)
> >
> >> Is this data mutable and should it really be in data segment and not in rodata?
> >> 
> >
> > I think it should be in rodata.
> 
> So it is not a bug and not a feature. It is just because it does not matter? Maybe a feature request?

Seems to happen only for the TypeInfo init symbols. I can't run the testsuite right now, but try this:

diff --git a/gcc/d/d-decls.cc b/gcc/d/d-decls.cc
index bd6f5f9..45d433a 100644
--- a/gcc/d/d-decls.cc
+++ b/gcc/d/d-decls.cc
@@ -274,6 +274,8 @@ TypeInfoDeclaration::toSymbol (void)
       // given TypeInfo.  It is the actual data, not a reference
       gcc_assert (TREE_CODE (TREE_TYPE (csym->Stree)) ==
REFERENCE_TYPE); TREE_TYPE (csym->Stree) = TREE_TYPE (TREE_TYPE
(csym->Stree));
+      TREE_CONSTANT (csym->Stree) = true;
+      TREE_READONLY (csym->Stree) = true;
       relayout_decl (csym->Stree);
       TREE_USED (csym->Stree) = 1;

On Thursday, 14 August 2014 at 19:05:46 UTC, Johannes Pfau wrote:
> Am Thu, 14 Aug 2014 17:53:32 +0000
> schrieb "Timo Sintonen" <t.sintonen@luukku.com>:
>
>> On Thursday, 14 August 2014 at 17:13:23 UTC, Johannes Pfau wrote:
>> > Am Thu, 14 Aug 2014 10:07:04 +0000
>> > schrieb "Timo Sintonen" <t.sintonen@luukku.com>:
>> >
>> >> I have been looking at object files to see if I can reduce the memory usage for minimum systems. There are two things I have noticed:
>> >> 
>> >> 1. In the data segment there is some source code as ascii text from a template in gcc/atomics.d . This is in the actual data segment and not in debug info segments and goes into the data segment of the executable. I do not see any code using this data. Why is this in the executable and is it possible to remove it?
>> >> 
>> >
>> > Strange, could you post a testcase?
>> It seems this comes from libdruntime and it exists in object.o and core/atomic.o, Testcase is to compile minlibd library as it is currently in the repo using the makefile as such.
>> But I think it will be in any object file that imports gcc.atomics and uses the template in there.
>> 
>
> If you're referring to this:
> http://dpaste.dzfl.pl/fe75e8c7dfca
>
> This seems to be the const variable in __sync_op_and. Try to change the
> code to "immutable __sync_op_and = " or "enum __sync_op_and = " and
> file a bug report.
>
>> >
>> >> 2. In the data segment there is also __init for all types. I assume that they contain the initial values that are copied when a new object of this type is created.
>> >
>> > Correct, it's for '.init' (there's especially __..._TypeInfo_init which
>> > is the initializer for typeinfo. I've implemented -fno-rtti in a private
>> > git branch to get rid of typeinfo)
>> >
>> >> Is this data mutable and should it really be in data segment and not in rodata?
>> >> 
>> >
>> > I think it should be in rodata.
>> 
>> So it is not a bug and not a feature. It is just because it does not matter? Maybe a feature request?
>
> Seems to happen only for the TypeInfo init symbols. I can't run the
> testsuite right now, but try this:
>
> diff --git a/gcc/d/d-decls.cc b/gcc/d/d-decls.cc
> index bd6f5f9..45d433a 100644
> --- a/gcc/d/d-decls.cc
> +++ b/gcc/d/d-decls.cc
> @@ -274,6 +274,8 @@ TypeInfoDeclaration::toSymbol (void)
>        // given TypeInfo.  It is the actual data, not a reference
>        gcc_assert (TREE_CODE (TREE_TYPE (csym->Stree)) ==
> REFERENCE_TYPE); TREE_TYPE (csym->Stree) = TREE_TYPE (TREE_TYPE
> (csym->Stree));
> +      TREE_CONSTANT (csym->Stree) = true;
> +      TREE_READONLY (csym->Stree) = true;
>        relayout_decl (csym->Stree);
>        TREE_USED (csym->Stree) = 1;

Looks good. Template code is gone and init blocks have moved to rodata. My simple test program compiles and runs.

There is still some __Class in data segment and init values for structs and arrays in bss segment. Is it possible to move these to rodata too?


In my application there will be several large structs. I never create anything of these types. Instead I use them to point to hardware registers and maybe on top of existing byte arrays like message buffers. There will still be initial values for these structs wasting memory. Is there any way to omit them?

On Sat, 16 Aug 2014 07:06:34 +0000
"Timo Sintonen via D.gnu" <d.gnu@puremagic.com> wrote:

> structs wasting memory. Is there any way to omit them?
maybe this will work:

struct A {
  int n = void;
  uint[2] a = void;
  ...and so on for all fields
}

Am Sat, 16 Aug 2014 07:06:34 +0000
schrieb "Timo Sintonen" <t.sintonen@luukku.com>:

> On Thursday, 14 August 2014 at 19:05:46 UTC, Johannes Pfau wrote:
> > Am Thu, 14 Aug 2014 17:53:32 +0000
> > schrieb "Timo Sintonen" <t.sintonen@luukku.com>:
> >
> >> On Thursday, 14 August 2014 at 17:13:23 UTC, Johannes Pfau wrote:
> >> > Am Thu, 14 Aug 2014 10:07:04 +0000
> >> > schrieb "Timo Sintonen" <t.sintonen@luukku.com>:
> >> >
> >> >> I have been looking at object files to see if I can reduce the memory usage for minimum systems. There are two things I have noticed:
> >> >> 
> >> >> 1. In the data segment there is some source code as ascii text from a template in gcc/atomics.d . This is in the actual data segment and not in debug info segments and goes into the data segment of the executable. I do not see any code using this data. Why is this in the executable and is it possible to remove it?
> >> >> 
> >> >
> >> > Strange, could you post a testcase?
> >> It seems this comes from libdruntime and it exists in object.o
> >> and core/atomic.o, Testcase is to compile minlibd library as
> >> it is currently in the repo using the makefile as such.
> >> But I think it will be in any object file that imports
> >> gcc.atomics and uses the template in there.
> >> 
> >
> > If you're referring to this: http://dpaste.dzfl.pl/fe75e8c7dfca
> >
> > This seems to be the const variable in __sync_op_and. Try to
> > change the
> > code to "immutable __sync_op_and = " or "enum __sync_op_and = "
> > and
> > file a bug report.
> >
> >> >
> >> >> 2. In the data segment there is also __init for all types. I assume that they contain the initial values that are copied when a new object of this type is created.
> >> >
> >> > Correct, it's for '.init' (there's especially
> >> > __..._TypeInfo_init which
> >> > is the initializer for typeinfo. I've implemented -fno-rtti
> >> > in a private
> >> > git branch to get rid of typeinfo)
> >> >
> >> >> Is this data mutable and should it really be in data segment and not in rodata?
> >> >> 
> >> >
> >> > I think it should be in rodata.
> >> 
> >> So it is not a bug and not a feature. It is just because it does not matter? Maybe a feature request?
> >
> > Seems to happen only for the TypeInfo init symbols. I can't run
> > the
> > testsuite right now, but try this:
> >
> > diff --git a/gcc/d/d-decls.cc b/gcc/d/d-decls.cc
> > index bd6f5f9..45d433a 100644
> > --- a/gcc/d/d-decls.cc
> > +++ b/gcc/d/d-decls.cc
> > @@ -274,6 +274,8 @@ TypeInfoDeclaration::toSymbol (void)
> >        // given TypeInfo.  It is the actual data, not a
> > reference
> >        gcc_assert (TREE_CODE (TREE_TYPE (csym->Stree)) ==
> > REFERENCE_TYPE); TREE_TYPE (csym->Stree) = TREE_TYPE (TREE_TYPE
> > (csym->Stree));
> > +      TREE_CONSTANT (csym->Stree) = true;
> > +      TREE_READONLY (csym->Stree) = true;
> >        relayout_decl (csym->Stree);
> >        TREE_USED (csym->Stree) = 1;
> 
> Looks good. Template code is gone and init blocks have moved to rodata. My simple test program compiles and runs.
> 
> There is still some __Class in data segment and init values for structs and arrays in bss segment. Is it possible to move these to rodata too?
> 

Iain recently pushed a commit to put zero initializers into bss, so
that's intentional:
http://bugzilla.gdcproject.org/show_bug.cgi?id=139
But I understand your point that it should be in rodata instead, you'll
have to discuss this with Iain.

Regarding __Class: Can you post a short example?

> 
> In my application there will be several large structs. I never create anything of these types. Instead I use them to point to hardware registers and maybe on top of existing byte arrays like message buffers. There will still be initial values for these structs wasting memory. Is there any way to omit them?
> 

See
https://github.com/D-Programming-GDC/GDC/pull/82
@attribute("noinit")

On Saturday, 16 August 2014 at 07:36:07 UTC, Johannes Pfau wrote:

> Iain recently pushed a commit to put zero initializers into bss, so
> that's intentional:
> http://bugzilla.gdcproject.org/show_bug.cgi?id=139
> But I understand your point that it should be in rodata instead, you'll
> have to discuss this with Iain.

It is true that bss does not take place in the executable. But in small processors, even there is nowadays plenty of rom there is not enough ram. It is also a question of safety: in the long run, data area may be corrupted by buggy program or electrical distort while rodata in rom cannot be changed.
At least in my setup, gold maps bss to executable anyway while ld does not.

I noticed your comment in the bug report. I was just thinking the same: one big block of zeros that is used by all.
Another that I was thinking is that memset might be used for these types. Then there would be no block of zeros at all. But that would require an extra flag in typeinfo to separate these types from others...
>

> Regarding __Class: Can you post a short example?

Some lines from mapfile. Seems to be one for every type in the program:

 .data          0x0000000020001074      0x720 minlibd/libdruntime/libdruntime.a(object_.o)
                0x0000000020001074                _D9Exception7__ClassZ
                0x00000000200010c0                _D8TypeInfo7__ClassZ
                0x000000002000110c                _D17TypeInfo_Function7__ClassZ
                0x0000000020001158                _D17TypeInfo_Delegate7__ClassZ
                0x00000000200011a4                _D14TypeInfo_Class7__ClassZ
                0x00000000200011f0                _D18TypeInfo_Interface7__ClassZ
                0x000000002000123c                _D15TypeInfo_Struct7__ClassZ
                0x0000000020001288                _D16TypeInfo_Typedef7__ClassZ

>
>> 
>> In my application there will be several large structs. I never create anything of these types. Instead I use them to point to hardware registers and maybe on top of existing byte arrays like message buffers. There will still be initial values for these structs wasting memory. Is there any way to omit them?
>> 
>
> See
> https://github.com/D-Programming-GDC/GDC/pull/82
> @attribute("noinit")

Yes this will solve the problem.

Am Sat, 16 Aug 2014 08:39:04 +0000
schrieb "Timo Sintonen" <t.sintonen@luukku.com>:

> 
> > Regarding __Class: Can you post a short example?
> 
> Some lines from mapfile. Seems to be one for every type in the program:
> 
>   .data          0x0000000020001074      0x720
> minlibd/libdruntime/libdruntime.a(object_.o)
>                  0x0000000020001074
> _D9Exception7__ClassZ
>                  0x00000000200010c0
> _D8TypeInfo7__ClassZ
>                  0x000000002000110c
> _D17TypeInfo_Function7__ClassZ
>                  0x0000000020001158
> _D17TypeInfo_Delegate7__ClassZ
>                  0x00000000200011a4
> _D14TypeInfo_Class7__ClassZ
>                  0x00000000200011f0
> _D18TypeInfo_Interface7__ClassZ
>                  0x000000002000123c
> _D15TypeInfo_Struct7__ClassZ
>                  0x0000000020001288
> _D16TypeInfo_Typedef7__ClassZ
> 

I just had a look at this and ClassInfo has a mutable 'monitor' field, so it can't be placed into read-only data.