<html>
<head>
<base href="http://bugzilla.gdcproject.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - TypeInfo.name strings don't get put into separate sections when compiling with -fdata-sections"
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=184">184</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>TypeInfo.name strings don't get put into separate sections when compiling with -fdata-sections
</td>
</tr>
<tr>
<th>Product</th>
<td>GDC
</td>
</tr>
<tr>
<th>Version</th>
<td>development
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>major
</td>
</tr>
<tr>
<th>Priority</th>
<td>Normal
</td>
</tr>
<tr>
<th>Component</th>
<td>gdc
</td>
</tr>
<tr>
<th>Assignee</th>
<td>ibuclaw@gdcproject.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>slavo5150@yahoo.com
</td>
</tr></table>
<p>
<div>
<pre>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
(<a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192</a>), 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:
<a href="http://forum.dlang.org/post/m98a61$qp$1@digitalmars.com">http://forum.dlang.org/post/m98a61$qp$1@digitalmars.com</a>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>