<div dir="ltr">Thanks Jan,<div><br></div><div>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.</div><div><br></div><div>I'll tinker around with this idea in a local branch while waiting to see if anyone else has any input.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 1:25 PM Jan Kratochvil <<a href="mailto:jan.kratochvil@redhat.com">jan.kratochvil@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 11 Mar 2019 20:45:48 +0100, Zachary Turner via lldb-dev wrote:<br>
> I want to ask what the status of DWARF64 in LLDB is.<br>
<br>
IMO there isn't as for example:<br>
lldb/source/Plugins/SymbolFile/DWARF/DIERef.cpp<br>
is using bits 32..63 for additional info (DWO file offset/index for example)<br>
while only bits 0..31 are used for DIE offset inside .debug_info section.<br>
<br>
lldb/include/lldb/Core/dwarf.h<br>
#ifdef DWARFUTILS_DWARF64<br>
but nobody ever defines DWARFUTILS_DWARF64 and so it uses:<br>
typedef uint32_t dw_offset_t; // Dwarf Debug Information Entry offset for any<br>
// offset into the file<br>
<br>
<br>
> For example, I > know that clang and LLVM will not even generate DWARF64,<br>
<br>
Even GCC needs to be patched to generate DWARF64.<br>
<br>
<br>
> Certainly we can improve LLVM's support for consuming DWARF64, but it's a<br>
> question of priorities.<br>
<br>
I think it is never needed in real world as long as one uses DWP and/or<br>
-fdebug-types-section. Red Hat is using neither (for DWZ postprocessing) and<br>
so I did hit this limit of unsupported DWARF64 in GNU utilities [attached].<br>
<br>
<br>
Jan<br>
<br><br><br>---------- Forwarded message ----------<br>From: Jan Kratochvil <<a href="mailto:jan.kratochvil@redhat.com" target="_blank">jan.kratochvil@redhat.com</a>><br>To: <a href="mailto:xxx@redhat.com" target="_blank">xxx@redhat.com</a><br>Cc: <br>Bcc: <br>Date: Wed, 8 Aug 2018 15:14:16 +0200<br>Subject: DWARF64 for Chromium with 10GB of DWARF<br>Hello,<br>
<br>
LLDB people were talking about 6GB Chromium binaries. So I checked Fedora<br>
Chromium but:<br>
# Debuginfo packages aren't very useful here. If you need to debug<br>
# you should do a proper debug build (not implemented in this spec yet)<br>
%global debug_package %{nil}<br>
and it uses no '-g' during compilation.<br>
<br>
After enabling Chromium debug info [attached, it has only -g2, not -g3] I got:<br>
obj/mojo/public/cpp/system/system/message_pipe.o:(.debug_loc+0x1bcc): relocation truncated to fit: R_X86_64_32 against `.debug_info'<br>
...<br>
obj/third_party/blink/renderer/platform/platform/fe_convolve_matrix.o:(.debug_info+0x4b5dc): additional relocation overflows omitted from the output<br>
collect2: error: ld returned 1 exit status<br>
<br>
Which is logical as Chromium has 8GB of .debug_info section. I found no gcc<br>
option to enable 64-bit DWARF so I had to patch GCC for that [attached].<br>
<br>
But then the rpmbuild failed a different way:<br>
<br>
/usr/lib/rpm/debugedit: BUILDROOT/chromium-67.0.3396.87-2.fc28.x86_64/usr/lib64/chromium-browser/libEGL.so: 64-bit DWARF not supported<br>
...<br>
eu-strip: elf32_updatefile.c:336: __elf64_updatemmap: Assertion `dl->data.d.d_size <= (shdr->sh_size - (GElf_Off) dl->data.d.d_off)' failed.<br>
/usr/lib/rpm/find-debuginfo.sh: line 231: 3998449 Aborted eu-strip --remove-comment $r $g ${keep_remove_args} -f "$1" "$2"<br>
double free or corruption (out)<br>
/usr/lib/rpm/find-debuginfo.sh: line 231: 3998529 Aborted eu-strip --remove-comment $r $g ${keep_remove_args} -f "$1" "$2"<br>
dwz: ./etc/chromium/native-messaging-hosts/remoting_user_session-67.0.3396.87-2.fc28.x86_64.debug: 64-bit DWARF not supported<br>
<br>
DWZ would be unable to handle it on x86_64 even if it did support DWARF64 as<br>
rpmbuild limits it to 110e6 DIEs while this DWARF has 500e6 DIEs.<br>
<br>
Google AFAIK builds it with -gsplit-dwarf and then one can pack the *.dwo<br>
files into EXEC.dwp by /usr/bin/dwp (llvm-dwp in the Google case).<br>
DWZ-like optimization is then achieved by -fdebug-types-section.<br>
But then rpmbuild is not prepared to handle *.dwp (like current *.debug).<br>
<br>
The 10GB DWARF64 binary if anyone is interested:<br>
<a href="https://www.jankratochvil.net/t/chromium-headless_shell.xz" rel="noreferrer" target="_blank">https://www.jankratochvil.net/t/chromium-headless_shell.xz</a><br>
<br>
Then it is questionable whether to deal with DWARF64/DWP just for Chromium.<br>
Customers really do not have binaries of this DWARF size?<br>
<br>
<br>
Jan<br>
_______________________________________________<br>
<br>
<br>
</blockquote></div>