使用-gline表而不是-g的缺点是什么？
我项目使用-G生成的调试信息增加了大量的二进制尺寸和编译时间开销。我想使用精益的-gline-tables--，但不确定我会丢失什么。例如，线断点仍然可以工作吗？ LLDB中的p var_name呢？我正在使用clang和Swiftc，这两者都取决于LLVM。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
-gline-tables-实际上确实只记录了调试信息的地址 - 线号部分。因此，通过file＆amp;行大部分仍将工作（某些内部信息不在官方的“线表”中，并且会丢失），您会在回溯中看到线信息。
但是，它缺少所有范围/变量/类型信息。因此，消费者不知道当前范围或程序中的任何地方都有哪些变量（因此
v，而您的IDE本地视图将无法正常工作）。即使它确实知道变量也无法打印它，因为LLDB也不知道类型。因此，您也不能真正使用expr铸造和打印原始地址。-gline-tables-仅在您真正关心的只是从崩溃报告等中获取行号信息时，对于长期存储调试信息很有用。它对于实际调试并不有用。
-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
vand 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 useexprto 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.