Am Thu, 15 Jan 2015 23:08:57 -0600
schrieb "Orvid King via D.gnu" <d.gnu@puremagic.com>:
> On 1/15/2015 10:31 PM, Mike via D.gnu wrote:
> > On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:
> >
> >> My best guess is that the strings are always placed in rodata,
> >> never in separate sections. If you do write("x"), "x" is also in
> >> rodata, the rodata section can't be removed. If you delete the
> >> write call there's no reference to rodata and it's possible to
> >> remove the complete section.
> >>
> >> After some google-fu:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
> >> Considering this was filed in 2000 I'd say it's not very likely to
> >> get fixed soon :-(
> >>
> >> So the best option is probably to get rid of this problem by
> >> patching the compiler (@notypeinfo or -fnortti).
> >
> > Here's a filthy sed hack to workaround this bug:
> >
> > 1) compile to assembly:
> > -----------------------------------------------
> > gdc -S -static -frelease -fno-emit-moduleinfo -nophoboslib
> > -nostdlib test.d --entry=main -ffunction-sections -fdata-sections
> > -Wl,--gc-sections -o test_temp.s
> >
> > 2) use sed to modify the assembly, putting each
> > string into its own section:
> > -----------------------------------------------
> > sed -e 's/^\(\.LC[0-9]*\)\(\:\)/\.section .rodata\1\n\1\2/g'
> > test_temp.s >test.s
> >
> > 3) compile the new assembly:
> > -----------------------------------------------
> > as test.s -o test.o
> >
> > 4) link:
> > -----------------------------------------------
> > ld test.o --entry=main --gc-sections -o test
> >
> > 5) verify:
> > -----------------------------------------------
> > objdump -s -j .rodata test
> >
> > Contents of section .rodata:
> > 400168 780a x.
> >
> > size test
> > text data bss dec hex filename
> > 338 0 0 338 152 test
> >
> > 6) execute:
> > ------------------------------------------------
> > ./test
> > x
> >
> > Filthy, but cheap and effective. Fortunately it's all automated
> > with rdmd.
> >
> > Mike
>
> The problem with this is that the TypeInfo is used for a significant
> number of things in the runtime, casting, allocation, and
> initialization just to name a few.
Mike doesn't use the runtime so this is less of a problem. And in many
cases the compiler already avoids TypeInfo: Default initializers are
separate symbols and don't require TypeInfo. Allocation: Only GC
allocation is affected, custom allocators are templates.
Casting: AFAIK only for class downcasts. This is probably the most
important feature requiring TypeInfo. Here we might prefer a minimal
classinfo instead of completely removing it.
> The type info for structures is
> already only generated if it's allocated on the heap.
Either I don't understand what you mean or you're wrong ;-) TypeInfo is
generated at declaration time. At that point you can't even know if
a struct will be allocated on the heap at some point. Maybe you're
talking about closures? It is true that _GC_ heap allocation requires
TypeInfo but that's usually considered a bug.
> I suspect
> though that I'm probably just too tired right now to understand the
> intricacies of the topic.
