On 12 February 2015 at 10:29, Steve Kargl
> Does this feature take into account the optimization level
> that one may set via CFLAGS? Conventional wisdom used to
> claim that debuggers did not fair too well with code that
> was compiled with -O2 (or -Os and/or other well-known gcc
> options -fomit-frame-pointer, etc.) The common advice was
> to recompile one's code with -g or '-g -O'. Does lldb cope
> better with optimized binaries?
The WITH_DEBUG_FILES option builds debug regardless of what
optimization level is set. I'm not quite sure in which way
WITH_DEBUG_FILES would take account of the optimization level.
It's true that debugging is easier if the target is built with -O0.
If I have a reproducible crash as a developer, I would rebuild with
-O0. That may not be feasible for end users though, and doesn't help
in the case of a crash that can't be reproduced.
That said, debugging is still possible with -O2, it just loses
information or makes control flow hard to follow in some (perhaps
many) cases. Type and source line information is still available. It
may not be possible to read the value of some variables at some times
during execution, and stepping can be confusing. But it's usually
possible to get a useful backtrace and find necessary variables.
All of my systems are built with -O2 and WITH_DEBUG_FILES, and
generally speaking I have a positive experience with postmortem
debugging of core files.
LLDB does handle optimized binaries better than the ancient version of
GDB we have in the base system. Contemporary GDB versions also do so.
Also note that for userland DTrace support we build with -g as part of
the process of generating CTF information, so enabling userland DTrace
also implies an increase in OBJDIR size.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"