On 12 February 2015 at 10:29, Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote: > > 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.Received on Thu Feb 12 2015 - 16:55:17 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:55 UTC