[lldb-dev] Status of DWARF64 in LLDB

[Adrian Prantl via lldb-dev]

> On Mar 11, 2019, at 3:46 PM, Zachary Turner <zturner at google.com> wrote:
> 
> 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

I'm supportive of removing DWARF64 support from LLDB.

-- adrian

> 
> On Mon, Mar 11, 2019 at 3:33 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> 
> 
> > On Mar 11, 2019, at 12:45 PM, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org <mailto: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/04fd1eaf/attachment.html>