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

Reply via email to