[Bug 184] New: TypeInfo.name strings don't get put into separate sections when compiling with -fdata-sections

[via D.gnu]

http://bugzilla.gdcproject.org/show_bug.cgi?id=184

            Bug ID: 184
           Summary: TypeInfo.name strings don't get put into separate
                    sections when compiling with -fdata-sections
           Product: GDC
           Version: development
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: Normal
         Component: gdc
          Assignee: ibuclaw at gdcproject.org
          Reporter: slavo5150 at yahoo.com

Consider the following code:

***************************
module test;

long sys_write(long arg1, in void* arg2, long arg3) nothrow
{
    long result;

    asm
    {
        "syscall"
        : "=a" result
        : "a" 1,
        "D" arg1,
        "S" arg2,
        "m" arg2,
        "d" arg3
        : "memory", "cc", "rcx", "r11";
    }

    return result;
}

void write(in string text) nothrow
{
    sys_write(2, text.ptr, text.length);
}

void write(A...)(in A a) nothrow
{
    foreach(t; a)
    {
        write(t);
    }
}

final abstract class TestClass1 { }
final abstract class TestClass2 { }
final abstract class TestClass3 { }
final abstract class TestClass4 { }
final abstract class TestClass5 { }
final abstract class TestClass6 { }
final abstract class TestClass7 { }
final abstract class TestClass8 { }
final abstract class TestClass9 { }

extern(C) void main()
{
    write("x");
}
**********************************


Compile with:
-------------
gdc -static -frelease -fno-emit-moduleinfo -nophoboslib -nostdlib test.d
--entry=main -ffunction-sections -fdata-sections -Wl,--gc-sections -o test


Examining the .rodata section we see:
-------------------------------------
objdump -s -j .rodata test | grep "TestClass" 
 42edf0 74657374 2e546573 74436c61 73733100  test.TestClass1.
 42ee40 74657374 2e546573 74436c61 73733200  test.TestClass2.
 42ee90 74657374 2e546573 74436c61 73733300  test.TestClass3.
 42eee0 74657374 2e546573 74436c61 73733400  test.TestClass4.
 42ef30 74657374 2e546573 74436c61 73733500  test.TestClass5.
 42ef80 74657374 2e546573 74436c61 73733600  test.TestClass6.
 42efd0 74657374 2e546573 74436c61 73733700  test.TestClass7.
 42f020 74657374 2e546573 74436c61 73733800  test.TestClass8.
 42f070 74657374 2e546573 74436c61 73733900  test.TestClass9.

The "test.TestClassX." strings appears to be the TypeInfo.name field.  If
compiling with -fdata-sections, these should be put into individual sections so
they can be garbage-collected by --gc-sections

However, although compiled with the -fdata-sections flag, they are always
placed in .rodata.  I thought that this was related to GCC bug 192
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192), but a recent patch to fix
that bug, did not solve this problem, therefore, I'm assuming this is an
artifact of DMD's/GDC's codegen.

Why this is a major problem
---------------------------
In my project, I make use of a highly-templated memory-mapped IO library to
describe the memory layout of registers statically.  This results in 100s of
small static types.  Since the TypeInfo.name strings are not garbage-collected,
the resulting binary results grows to over several 100k, when it should be less
than 10k.  This prevents the binary from being small enough to load into flash
memory of some microcontrollers, when the vast majority of the data in the
binary is never used.

This problem was discussed on the GDC forum: 
http://forum.dlang.org/post/m98a61$qp$1@digitalmars.com

It appears we may get an -fno-rtti option soon which will alleviate this
problem temporarily, but when TypeInfo is eventually implemented and used in a
more full-featured runtime, this will become a major problem again.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20150511/585645a7/attachment.html>