Home > Back-end >  What are the downsides of using -gline-tables-only instead of -g?
What are the downsides of using -gline-tables-only instead of -g?

Time:05-17

The debug info generated with -g for my project adds a substantial amount of binary size and compilation time overhead. I'd like to use the leaner -gline-tables-only, but am not sure what I'd be losing. For example, would line breakpoints still work? What about p var_name in LLDB? I'm using clang and swiftc, which both depend on LLVM.

CodePudding user response:

-gline-tables-only really does only record the address->line number part of the debug information. So break setting by file & line will mostly still work (some of the inlining information doesn't go in the official "line table", and that will be missing), and you will see line information in backtraces.

However, it lacks all the scope/variable/type information. So the consumer won't know what variables there are in the current scope, or really anywhere in your program (so v and your IDE's Locals view won't work). And even if it did know about a variable wouldn't be able to print it because lldb also wouldn't know the type. So you can't really use expr to cast and print raw addresses either.

-gline-tables-only is useful for long term storage of debug info when all you really care about is getting line number info out of crash reports and the like. It isn't useful for actual debugging.

  • Related