> On Mar 11, 2019, at 3:46 PM, Zachary Turner <ztur...@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 <apra...@apple.com 
> <mailto:apra...@apple.com>> wrote:
> > On Mar 11, 2019, at 12:45 PM, Zachary Turner via lldb-dev 
> > <lldb-dev@lists.llvm.org <mailto:lldb-dev@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

lldb-dev mailing list

Reply via email to