Enable stack frames for release builds

[CyberShadow]

https://issues.dlang.org/show_bug.cgi?id=13726

[MartinNowak]

That might actually cost performance.

[CyberShadow]

I think you've closed this a bit hastily. I've been planning to create this pull request for a year or more. I've raised the issue on the newsgroups before as well, and IIRC there were no objections.

[MartinNowak]

We have deficiencies in the stack unwinder, eh infos, and backtraces, but not in the stack layouts.
This is just fixing a symtptom and will add a tiny overhead to any D program.
The best thing to improve debugging would be to also release debug Phobos build.

[CyberShadow]

This is just fixing a symtptom

I don't understand this argument.

and will add a tiny overhead to any D program.

It is indeed quite tiny. I've measured 0.1% in two different benchmarks.

I think it is a worthwhile tradeoff.

The best thing to improve debugging would be to also release debug Phobos build.

I understand that by a debug Phobos build you mean one built without -O, -inline or -release. This will help some situations but not others. A debug Phobos build is useful when debugging Phobos itself, but otherwise the overhead of disabling optimizations will affect normal usage too much.

For example, using a polling profiler (Very Sleepy) requires correct call stacks for call tree profiling. Stack frames enable this, however using a debug (unoptimized) build of Phobos/Druntime would significantly skew the profiling results.

Another example is running a daemon / web service. DFeed, the Digger GitHub proxy, the D Wiki CAPTCHA service are all built against Phobos/Druntime with stack frames enabled so that the stack frames are legible when the service crashes (I get an email with the stack trace and the service restarts automatically). Using a debug Phobos/Druntime for this in production would be unsuitable.

Including a build of Phobos/Druntime with just stack frames enabled would fix the above cases, but I doubt it will happen. The difference between the release build is too minute to justify the package filesize increase.

In any case, this change is much simpler than introducing a debug Phobos build into D packaging.

[rainers]

See also https://issues.dlang.org/show_bug.cgi?id=11014.

It's not only stack traces for code from a release build of phobos that fails to show a sensible call stack, it is even a throw from user code with full debug info.

@CyberShadow Have you tried if it is better with debug symbols built into phobos, but without standard stack frame.

Maybe this is mostly a Win32 problem, so we might be fine with just enabling standard stack frames in win32.mak?

[CyberShadow]

@CyberShadow Have you tried if it is better with debug symbols built into phobos, but without standard stack frame.

Phobos is already built with debug symbols (-g).

Maybe this is mostly a Win32 problem, so we might be fine with just enabling standard stack frames in win32.mak?

I have noticed improvements after adding -gs in Win32 and Linux/64. Haven't tried Win64 or Win32/COFF.

However, I just looked at the disassembly of a Win64 program compiled with and without -gs. It looks like DMD adds stack frames regardless of -release and -gs: the push rbp / mov rbp, rsp prolog and pop rbp epilog is always there.

[rainers]

Phobos is already built with debug symbols (-g).

Not in the makefiles I see on master (apart of some unittests).

[MartinNowak]

For example, using a polling profiler (Very Sleepy) requires correct call stacks for call tree profiling.

But you loose part of that information with inlining too. And profilers also understand more complex stack formats if the compiler emits the correct information.
What we should really do IMO is to implement unwinding according to the platform/architecture ABI.

[CyberShadow]

Not in the makefiles I see on master (apart of some unittests).

Oops, that's right. Why is this? Debug symbols only add to the file size, and don't affect performance, right?

What we should really do IMO is to implement unwinding according to the platform/architecture ABI.

Again, what does unwinding have to do with call stacks? At least on Win32, exception unwinding can skip multiple function stack frames at once, if they do not have any EH constructs.

[rainers]

Oops, that's right. Why is this? Debug symbols only add to the file size, and don't affect performance, right?

OPTLink chokes on too much debug info, and phobos might add to that pretty well. I cannot build the release version of Visual D with debug information because of that (even without phobos debug info).

I browsed the dmd source, and the only effect of debug info on code generation is some disabling of instruction reordering for ELF/Mach-O in cod3.c(2985).

[CyberShadow]

cod3.c(2985)

Which happens to be inside the function which emits the stack frame instructions, heh.