When a freeware or trial program crashes on the user's computer, you have only one chance to get the error report. Because after that the unsatisfied customer will probably uninstall the application. That means even the finished production code should contain some sort of debug info.
Every serious developer (including the FPC and Lazarus teams) needs error reports from their customers. Unfortunately, in FPC there's no good compromise between reasonable executable file size and debug information.
One of the most useful things to a programmer is the call stack. Since release code contains no range checking, other debug symbols aren't that useful. So, here's my suggestion about a useful release-code call stack:
1. Add a new compiler directive (say {$CALLSTACK ON} and {$CALLSTACK OFF}). Any procedure or function between these two directives would have additional entry code to add the FileName.ClassName.FunctionName to the call stack and remove it upon function exit.
2. Since constantly repeating FileName and ClassName can occupy lots of space, there should be a table of file and class names, so that function entry code contains just an index to the file and class tables, plus the function name.
3. Make public functions to retrieve the call stack as a string at any moment. So the call stack can be stored, displayed, or uploaded to developer's site as a part of bug report.
For now there's no such option. Yes, one could turn full debug symbols on, but that's a waste of space, since it contains too much. We also have {$I %FILE%} and {$I %LINE%} directives, but not the {$I %FN%} directive to insert the function/procedure name. Because you don't always have the source for that particular version of the module, so the line number may point to another function.
If the system described above would be implemented, customer bug reports would become much more useful, while at the same time executable files wouldn't grow too much in size.