May 20, 2016
Poking the mail list as it doesn't seem to be explained in details on dlang.org

Recently we got to situation where it has become necessary to package both debug and release builds of runtime because keeping asserts/contracts in runtime has huge negative performance impact (2x slowdown for some of our projects). I hoped to make use of built in -defaultlib / -debuglib switches to link to correct one automatically but was quite surprised to find out that -debuglib is only used when -g flag is supplied. Presence or absence of -release / -debug make no difference here, only -g.

Is this by design? Would that be something you could consider changing? Keeping debug symbols in libraries has very low performance impact compared to keeping contracts, there doesn't seem to be any practical reason to connect linking special kind of library to it.


May 20, 2016
On 20 May 2016, at 17:28, Михаил Страшун via dmd-internals wrote:
> Is this by design? Would that be something you could consider changing?
> Keeping debug symbols in libraries has very low performance impact
> compared to keeping contracts, there doesn't seem to be any practical
> reason to connect linking special kind of library to it.

For LDC (where we have actually been shipping a debug build for a long time), I found that there is really no good option of tying the defaultlib/debuglib selection to. As you also discovered, some of the druntime contracts turn constant-time operations into linear-time ones and things like that.

What I ended up doing is to introduce a `-link-debuglib` switch so that people can choose explicitly (but the libraries can still be set up in the config file and so on). This might not be compatible with DMD's command line design philosophy, of course, but you might find some more background information searching our GitHub project for "debuglib".

 — David

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals