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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
