On Thu, 24 Sep 2020 20:10:45 +0200, Neal Gompa wrote: > I do not feel that this is a valid premise either, since the reason > for no dwz support in LLDB is because nobody contributed it. > I'm slightly surprised that Red Hat's debuginfo engineers hadn't already > contributed support for it into LLDB. I have implemented the support for DWZ into LLDB, it is just off-trunk now: https://people.redhat.com/jkratoch/dwz-2020-05-31/ https://copr.fedorainfracloud.org/coprs/jankratochvil/lldb/package/lldb-experimental/ dnf copr enable jankratochvil/lldb;dnf install lldb-experimental;lldb-experimental The problem is that the support is complicated as it has to affect the whole LLDB DWARF codebase (handling of each DIE type). That is the line based on my patchset, it is exactly calculated: https://fedoraproject.org/wiki/Changes/DebugInfoStandardization#Detailed_Description DWZ disadvantage: DWZ requires 8x times more complicated (LoC count) support in consumers than -fdebug-types-section. And all this support is needed despite almost nobody from LLDB/LLVM users (Android, iOS, OSX, still AFAIK Ubuntu/Debian) uses DWZ. So when DWZ brings almost no size benefits compared to much easier to support, faster to compile and already better supported by existing consumers (*) why not to switch to -fdebug-types-section? (*) such as LLDB and LLVM binutils but DWZ strings are not decoded even for example with binutils readelf > I wonder if the reason for that was the mistaken impression that dwz wasn't > broadly used. >From LLDB point of view users of DWZ-built Linux distros are counted in millions, users of Android/iOS/OSX are counted in billions. :-) Thanks for reply, Jan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
