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.
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.
I want to ask what the status of DWARF64 in LLDB is.
IMO there isn't as for example:
lldb/source/Plugins/SymbolFile/DWARF/DIERef.cpp
is using bits 32..63 for additional info (DWO file offset/index for example)
while only bits 0..31 are used for DIE offset inside .debug_info section.
lldb/include/lldb/Core/dwarf.h
#ifdef DWARFUTILS_DWARF64
but nobody ever defines DWARFUTILS_DWARF64 and so it uses:
typedef uint32_t dw_offset_t; // Dwarf Debug Information Entry offset for any
// offset into the file
For example, I > know that clang and LLVM will not even generate DWARF64,
Even GCC needs to be patched to generate DWARF64.
Certainly we can improve LLVM's support for consuming DWARF64, but it's a
question of priorities.
I think it is never needed in real world as long as one uses DWP and/or
-fdebug-types-section. Red Hat is using neither (for DWZ postprocessing) and
so I did hit this limit of unsupported DWARF64 in GNU utilities [attached].
Jan
dwarf64.patch (464 Bytes)
chromium-g2.patch (1.25 KB)
Thanks Jan,
That was my suspicion as well. If it’s true that DWARF64 support is currently non-functional, then I think the easiest path forward is to remove any traces of it from LLDB as a way of bringing the two implementations closer together.
I’ll tinker around with this idea in a local branch while waiting to see if anyone else has any input.
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
Given that:
-
LLVM doesn’t produce DWARF64
-
GCC has to be patched to produce DWARF64
-
LLDB’s support is only partial but is untested and appears to be missing major pieces in order for it to work
-
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
Given that:
-
LLVM doesn’t produce DWARF64
-
GCC has to be patched to produce DWARF64
-
LLDB’s support is only partial but is untested and appears to be missing major pieces in order for it to work
-
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
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.
Sounds good to me as well. We may need to add it in the next few
years, but simplifying interfaces for now sounds entirely reasonable.
-eric
FYI chromium-67.0.3396.87.rpm built with gcc-8.3.1-2.fc29.x86_64 DWARF-4
-fdebug-types-section has 1.6GB .debug_info and 0.5GB .debug_types:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[30] .debug_aranges PROGBITS 0000000000000000 000360 7a7630 00 0 0 16
[31] .debug_info PROGBITS 0000000000000000 7a7990 5e358d47 00 0 0 1
[32] .debug_abbrev PROGBITS 0000000000000000 5eb006d7 716d053 00 0 0 1
[33] .debug_line PROGBITS 0000000000000000 65c6d72a c686a97 00 0 0 1
[34] .debug_str PROGBITS 0000000000000000 722f41c1 21c96669 01 MS 0 0 1
[35] .debug_loc PROGBITS 0000000000000000 93f8a82a 24b3a638 00 0 0 1
[36] .debug_ranges PROGBITS 0000000000000000 b8ac4e62 ec29fd0 00 0 0 1
[37] .debug_types PROGBITS 0000000000000000 c76eee32 1cab0bd3 00 0 0 1
Jan
FWIW I would consider Chromium a medium sized project...
I'll see if I can grab some sample numbers of a few internal applications.
-eric