[Lldb-commits] [PATCH] D66791: [lldb][ELF] Read symbols from .gnu_debugdata sect.

Konrad Wilhelm Kleine via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Tue Aug 27 02:31:25 PDT 2019

kwk created this revision.
Herald added subscribers: llvm-commits, lldb-commits, MaskRay, hiraditya, arichardson, mgorny, emaste.
Herald added a reviewer: espindola.
Herald added projects: LLDB, LLVM.
kwk added reviewers: labath, jankratochvil.
kwk marked an inline comment as done.
kwk updated this revision to Diff 217331.
kwk added a comment.
kwk marked an inline comment as not done.

- Change header comment of minidebuginfo

Comment at: lldb/packages/Python/lldbsuite/test/linux/minidebuginfo/TestMiniDebugInfo.py:1
+""" Testing debugging of a binary with "mixed" dwarf (with/without fission). """
+import lldb
I just saw that this header makes no sense.

If the .symtab section is stripped from the binary it might be that
there's a .gnu_debugdata section which contains a smaller .symtab in
order to provide enough information to create a backtrace with function
names or to set and hit a breakpoint on a function name.

This change looks for a .gnu_debugdata section in the ELF object file.
The .gnu_debugdata section contains a xz-compressed ELF file with a
.symtab section inside. Symbols from that compressed .symtab section
are merged with the main object file's .dynsym symbols (if any).
In addition we always load the .dynsym even if there's a .symtab

For example, the Fedora and RHEL operating systems strip their binaries
but keep a .gnu_debugdata section. While gdb already can read this
section, LLDB until this patch couldn't. To test this patch on a
Fedora or RHEL operating system, try to set a breakpoint on the "help"
symbol in the "zip" binary. Before this patch, only GDB can set this
breakpoint; now LLDB also can do so without installing extra debug

  lldb /usr/bin/zip -b -o "b help" -o "r" -o "bt" -- -h

The above line runs LLDB in batch mode and on the "/usr/bin/zip -h"

  (lldb) target create "/usr/bin/zip"
  Current executable set to '/usr/bin/zip' (x86_64).
  (lldb) settings set -- target.run-args  "-h"

Before the program starts, we set a breakpoint on the "help" symbol:

  (lldb) b help
  Breakpoint 1: where = zip`help, address = 0x00000000004093b0

Once the program is run and has hit the breakpoint we ask for a

  (lldb) r
  Process 10073 stopped
  * thread #1, name = 'zip', stop reason = breakpoint 1.1
      frame #0: 0x00000000004093b0 zip`help
  ->  0x4093b0 <+0>:  pushq  %r12
      0x4093b2 <+2>:  movq   0x2af5f(%rip), %rsi       ;  + 4056
      0x4093b9 <+9>:  movl   $0x1, %edi
      0x4093be <+14>: xorl   %eax, %eax
  Process 10073 launched: '/usr/bin/zip' (x86_64)
  (lldb) bt
  * thread #1, name = 'zip', stop reason = breakpoint 1.1
    * frame #0: 0x00000000004093b0 zip`help
      frame #1: 0x0000000000403970 zip`main + 3248
      frame #2: 0x00007ffff7d8bf33 libc.so.6`__libc_start_main + 243
      frame #3: 0x0000000000408cee zip`_start + 46

In addition to supporting minidebuginfo this changes ensures that
yaml2obj doens't generate a .symtab section if there previously wasn't
any "Symbols" entry in the YAML file. Initially I planned to test my
code using LLDB-Lit but then I figured that it is necessary to not only
find a symbol but to make sure that we can also hit a breakpoint on a
symbol. I noticed during the development of this change, that one can
set a breakpoint but not necessarily hit it.

In order to support the .gnu_debugdata section, one has to have LZMA
development headers installed. The CMake section, that controls this
part looks for the LZMA headers and enables .gnu_debugdata support by
default if they are found; otherwise or if explicitly requested, the
minidebuginfo support is disabled.

GDB supports the "mini debuginfo" section .gnu_debugdata since v7.6

This is another error fixed by this commit that has nothing to do with
this change in general:

Fixed compile error: no memcpy in std ns

/home/kkleine/llvm/llvm/include/llvm/Support/MathExtras.h:271:8: error: no member named 'memcpy' in namespace 'std'; did you mean 'wmemcpy'?

  std::memcpy(in, &Val, sizeof(Val));

  rG LLVM Github Monorepo



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D66791.217331.patch
Type: text/x-patch
Size: 20357 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20190827/8f86e742/attachment-0001.bin>

More information about the lldb-commits mailing list