• bearophile (13/13) Jun 17 2013 I have compiled a small D program with LDC2 on Windows32, with
• David Nadlinger (14/18) Jun 18 2013 If you build with -g, the debug version of druntime/Phobos is linked
• bearophile (27/33) Jun 19 2013 On Windows32 with dmd the backtraces are unusable if you don't
• Richard Webb (10/15) Jun 19 2013 I was going to ask why a test app build with 'ldmd2 -inline

"bearophile" <bearophileHUGS lycos.com> writes:

I have compiled a small D program with LDC2 on Windows32, with 
and without -g and I have stripped it. Here are the resulting 
binary sizes:

2.166.124 test.exe  (1)
4.421.713 test_g.exe (2)
   853.518 test_stripped.exe (3)
1.204.750 test_g_stripped.exe (4)

What's the difference between the stripped (3) and the stripped 
program compiled with -g (4)?

Is it a good idea to make ldmd2 also strip the exe binary if the 
-g switch is not used?

Bye,
bearophile

"David Nadlinger" <code klickverbot.at> writes:

On 18 Jun 2013, at 1:09, bearophile wrote:
 What's the difference between the stripped (3) and the stripped 
 program compiled with -g (4)?

If you build with -g, the debug version of druntime/Phobos is linked 
instead.

 Is it a good idea to make ldmd2 also strip the exe binary if the -g 
 switch is not used?

Probably not, as that typically also makes backtraces rather unusable. 
We should look into other ways to reduce the executable size at some 
point though – currently, we don't allow the linker to easily strip 
out as much unused data as there would be possible (along the lines of 
-ffunction-sections resp. --gc-sections).

One thing I also want to look into is to automatically internalize 
everything on building executables that is not needed to be visible 
(like _Dmain, which is called from druntime). It would e.g. allow the 
LLVM optimizer to discard functions that have been inlined into all 
their callers, etc.

David

"bearophile" <bearophileHUGS lycos.com> writes:

David Nadlinger:

 If you build with -g, the debug version of druntime/Phobos is 
 linked instead.

I see.


 Is it a good idea to make ldmd2 also strip the exe binary if 
 the -g switch is not used?

 Probably not, as that typically also makes backtraces rather 
 unusable.

On Windows32 with dmd the backtraces are unusable if you don't 
compile with -g.

This is a little program:

void main() {
     throw new Exception(null);
}


If you compile it with dmd -g you get at run-time:

object.Exception test.d(2)
----------------
0x00402044 in _Dmain at ...\test.d(2)
0x0040292C in extern (C) int rt.dmain2._d_run_main(int, char**, 
extern (C) int function(char[][])*).void runMain()
0x004029BC in extern (C) int rt.dmain2._d_run_main(int, char**, 
extern (C) int function(char[][])*).void runAll()
...


If you don't use -g:

object.Exception test.d(2)
----------------
0x0040203D
0x00402914
0x00402231
0x00402054
...


Bye,
bearophile

"Richard Webb" <webby beardmouse.org.uk> writes:

On Wednesday, 19 June 2013 at 06:14:34 UTC, David Nadlinger wrote:
 On 18 Jun 2013, at 1:09, bearophile wrote:
 What's the difference between the stripped (3) and the 
 stripped program compiled with -g (4)?

 If you build with -g, the debug version of druntime/Phobos is 
 linked instead.


I was going to ask why a test app build with 'ldmd2 -inline 
-release -O -g' appears to be quite a bit slower than one built 
with 'ldmd2 -inline -release -O', and I suppose that answers that 
question as well?


(I thought i'd run it through the Very Sleepy Profiler to compare 
it with the version build with DMD. If i compile without -g then 
it works but I get no function names, and if I compile it with -g 
the profiler crashes (Doesn't seem to be an LDC issue though - It 
seems to have issues with Mingw 3.8 in general).