http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #9 from Kostya Serebryany <kcc at gcc dot gnu.org> --- (In reply to Joost VandeVondele from comment #8) > (In reply to Kostya Serebryany from comment #7) > > -fno-omit-frame-pointer: that may or may not be a good idea, I don't know. > > I seem to need it to get good backtraces (i.e. full stack, line numbers > etc.). Might be something I'm doing wrong, it is hard to figure out what the > best practice is. You do need -fno-omit-frame-pointer to get stack traces using our fast fp-based unwinder. The question is whether we want -fsanitize=x to enable -fno-omit-frame-pointer under the hood. My not-very-strong opinion is "no, make users read the documentation instead -- they have to do it anyway". > > I agree that -g incurs some overhead, but indeed, some line number > information is most helpful to debug the issues flagged by sanitizer. If > there are better approaches, they could indeed substitute the plain '-g'. Need to port -gmlt to gcc trunk. > > I hardly dare to mention it, but would be nice have these symbolic stacks > printed without the symbolize python script that seems needed now (and I > believe is not part of gcc). I believe in this context libbacktrace has been > metioned. We have a solution in the llvm-land: llvm-symbolizer https://code.google.com/p/address-sanitizer/wiki/CallStack You can build it (it's just a separate binary) and use it with gcc's asan. We have work-in-progress to make the symbolizer in-process as opposed to the current one that is out-of-process (uses pipes): https://code.google.com/p/address-sanitizer/source/browse/#svn%2Ftrunk%2Finternal_symbolizer