On 8/31/2011 1:19 PM, Steven Schveighoffer wrote:
It's also possible for the program to have its own seg fault handler that
reads its own symbolic debug info and generates a line number and stack trace.
There was a patch to Phobos that did this a while back.
This would also be a valid option. I have no idea why that wasn't included. Do
you?
Nobody spent the time to do it, mainly because it takes a fairly advanced low
level Windows programmer to understand and do it correctly.
Optlink's register dump on a seg fault is not Windows' doing, it installs a
seg fault handler which does this.
I predominantly use Linux, so Optlink/Windows tools really don't help. D is
supposed to support all OSes not just be useful on Windows.
Sure. It's just that since debuggers work on Linux, there should be no technical
reason why this cannot be made to work. Of course it will be very different code
than for Windows, but the user wouldn't see that.
On linux, the shell options are what determine whether the OS generates a core
dump, and by default they are off. It also does not hook seg faults to start a
debugger by default, it just says "Segmentation Fault" on the command line and
gives you a prompt. Useless.
> So 4 instructions per assert of a class reference (which is arguably not
common) is a lot of bloat?
15 bytes. And yes, this stuff adds up surprisingly quickly, especially if
you're the type that wants to leave the asserts on even in release mode.
How is this possible? I thought release mode removed asserts?
I misspoke. -release does remove the asserts, but some developers do not use
-release because they wish to leave the asserts on in their release builds.
Currently, the empty main() program is 256k. Add in writeln("hello, world") and
it adds 500k. Even if I had 10,000 asserts in there for objects, that adds 150k.
I think bloat can't possibly be a valid concern here.
You'd be surprised. I was surprised to discover that all the asserts in
std.datetime caused the unittest build of phobos to exceed all available memory
on my (old) FreeBSD box. (Jonathan used his own version of assert that uses more
runtime memory, he's got like 7500 in there.) Minimizing the footprint of
assert's reduces the resistance people have to using them.
Bloat can get to be a big problem if you're using templates, the templates
contain asserts, and those templates get inlined.
People have regularly complained about the size of D binaries.
Besides, you ignored my comment about how we can eliminate the bloat. Care to
respond?
I haven't thought about it.
