[lldb-dev] Status of DWARF64 in LLDB

[Zachary Turner via lldb-dev]

Given that:

1) LLVM doesn't produce DWARF64
2) GCC has to be patched to produce DWARF64
3) LLDB's support is only partial but is untested and appears to be missing
major pieces in order for it to work
4) It's of questionable use as there are several viable alternatives

Would it be reasonable to propose a patch removing the incomplete support
from LLDB?  We can always add it back later when someone is ready to really
support and test it properly, and the history in the repository will show
what code would need to be changed to get back to at least where the
support is today (which again, appears to not fully work).

If we can go this route, it makes merging the two DWARF parsing
implementations quite a bit simpler

On Mon, Mar 11, 2019 at 3:33 PM Adrian Prantl <aprantl at apple.com> wrote:

>
>
> > On Mar 11, 2019, at 12:45 PM, Zachary Turner via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >
> > I want to ask what the status of DWARF64 in LLDB is.  I can tell there's
> some support for it by reading the code, but it seems to have zero test
> coverage so it's not clear to me that anyone depends on it.  For example, I
> know that clang and LLVM will not even generate DWARF64, so if anyone is
> depending on it, they must be debugging programs built with some other
> toolchain.
>
> AFAIR, Apple's tools only generate/support DWARF32. After implementing
> type-uniquing in dsymutil we didn't see any individual .dSYM bundles that
> came even close to the 4GB watermark.
>
> >
> > I'm looking at unifying LLDB's DWARF parser with LLVM's, and this is the
> biggest functional difference I can see.
> >
> > Certainly we can improve LLVM's support for consuming DWARF64, but it's
> a question of priorities.  If nobody is actively depending on this, then
> taking a regression here could be on the table and then re-prioritizing
> adding back support in the future if / when we actually need it.
>
> -- adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190311/45b219db/attachment.html>