[lldb-dev] Status of DWARF64 in LLDB

[Zachary Turner via lldb-dev]

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.

On Mon, Mar 11, 2019 at 1:25 PM Jan Kratochvil <jan.kratochvil at redhat.com>
wrote:

> On Mon, 11 Mar 2019 20:45:48 +0100, Zachary Turner via lldb-dev wrote:
> > 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
>
>
>
> ---------- Forwarded message ----------
> From: Jan Kratochvil <jan.kratochvil at redhat.com>
> To: xxx at redhat.com
> Cc:
> Bcc:
> Date: Wed, 8 Aug 2018 15:14:16 +0200
> Subject: DWARF64 for Chromium with 10GB of DWARF
> Hello,
>
> LLDB people were talking about 6GB Chromium binaries. So I checked Fedora
> Chromium but:
>         # Debuginfo packages aren't very useful here. If you need to debug
>         # you should do a proper debug build (not implemented in this spec
> yet)
>         %global debug_package %{nil}
> and it uses no '-g' during compilation.
>
> After enabling Chromium debug info [attached, it has only -g2, not -g3] I
> got:
> obj/mojo/public/cpp/system/system/message_pipe.o:(.debug_loc+0x1bcc):
> relocation truncated to fit: R_X86_64_32 against `.debug_info'
> ...
> obj/third_party/blink/renderer/platform/platform/fe_convolve_matrix.o:(.debug_info+0x4b5dc):
> additional relocation overflows omitted from the output
> collect2: error: ld returned 1 exit status
>
> Which is logical as Chromium has 8GB of .debug_info section. I found no gcc
> option to enable 64-bit DWARF so I had to patch GCC for that [attached].
>
> But then the rpmbuild failed a different way:
>
> /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
> ...
> 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.
> /usr/lib/rpm/find-debuginfo.sh: line 231: 3998449 Aborted
>  eu-strip --remove-comment $r $g ${keep_remove_args} -f "$1" "$2"
> double free or corruption (out)
> /usr/lib/rpm/find-debuginfo.sh: line 231: 3998529 Aborted
>  eu-strip --remove-comment $r $g ${keep_remove_args} -f "$1" "$2"
> dwz:
> ./etc/chromium/native-messaging-hosts/remoting_user_session-67.0.3396.87-2.fc28.x86_64.debug:
> 64-bit DWARF not supported
>
> DWZ would be unable to handle it on x86_64 even if it did support DWARF64
> as
> rpmbuild limits it to 110e6 DIEs while this DWARF has 500e6 DIEs.
>
> Google AFAIK builds it with -gsplit-dwarf and then one can pack the *.dwo
> files into EXEC.dwp by /usr/bin/dwp (llvm-dwp in the Google case).
> DWZ-like optimization is then achieved by -fdebug-types-section.
> But then rpmbuild is not prepared to handle *.dwp (like current *.debug).
>
> The 10GB DWARF64 binary if anyone is interested:
>         https://www.jankratochvil.net/t/chromium-headless_shell.xz
>
> Then it is questionable whether to deal with DWARF64/DWP just for Chromium.
> Customers really do not have binaries of this DWARF size?
>
>
> Jan
> _______________________________________________
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190311/aa663a61/attachment.html>