Am Sat, 16 Aug 2014 07:06:34 +0000 schrieb "Timo Sintonen" <t.sinto...@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.sinto...@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.sinto...@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")
