[Lldb-commits] [PATCH] D106084: [DebugInfo] Switch to using constructor homing (-debug-info-kind=constructor) by default when debug info is enabled

David Blaikie via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Mon Jul 19 09:47:03 PDT 2021


dblaikie added a comment.

In D106084#2886659 <https://reviews.llvm.org/D106084#2886659>, @jmorse wrote:

> This is going to be excellent for linux targets and similar,
>
> In D106084#2882970 <https://reviews.llvm.org/D106084#2882970>, @probinson wrote:
>
>> + @jmorse who is better placed than I am to say whether this is what Sony would prefer.
>
> Slightly trickier -- our debugger won't resolve symbols across module boundaries (similar to the Windows debugger), which will make it hard to debug when debug/no-debug code is mixed. Would it be possible to default to `-debug-info-kind=limited` if `DebuggerTuning == llvm::DebuggerKind::SCE`? This leads to the fewest surprises in a default configuration targeting us.

It'd be preferable not to split these two cases (current "limited" versus "ctor" homing) - because they rely on the same assumption, that the whole program is built with debug info (hence the renaming of "limited" a long time ago to "standalone-debug" to create a policy/philosophy around what goes in each category).

Wouldn't the current "limited" behavior have problems for this shared libraries situation too? Sounds like in that case -fstandalone-debug should be used.

(if it's a sliding scale and the problems caused by the current -fno-standalone-debug/-flimit-debug-info are not severe enough, but ctor-homing would be too severe... I'd probably be inclined to pushback on that being a distinction we should draw in-tree & that might be suitable to be kept downstream)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106084/new/

https://reviews.llvm.org/D106084



More information about the lldb-commits mailing list