[Lldb-commits] [PATCH] D40475: DWZ 12/12: DWZ test mode

Jan Kratochvil via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Nov 30 02:04:51 PST 2017

jankratochvil added a comment.

> you will probably be the only person who will be able to run these tests and verify dwz functionality.

OK; really nobody runs RHEL/CentOS/Fedora? :-)

> If you don't setup a buildbot testing

OK, I will try that.  I was even running a test bot for GDB.

> These can range from checking in a couple of siple dwz files

OK; although during development various bugs required various testfiles, single testfiles does not catch it all but sure better than nothing.

> reimplementing/upstreaming the utilities necessary to build dwz files ourselves (I am not sure what the dwz tool does, but the eu-strip and sepdebugcrcfix tools sound like they would be fairly easy to implement on top of existing llvm libraries).

DWZ has its upstream sources <https://sourceware.org/git/?p=dwz.git>.
`eu-strip` is just a more optimized (and more ELF-details preserving) variant of GNU binutils `strip`. It should be easy to slightly extend `llvm-objcopy` (as there is no `llvm-strip`). Or is it OK to use GNU binutils `strip` instead?
`sepdebugcrcfix` is a small utility currently inside upstream `rpm` package so that could be reimplemented in LLVM.
Although I admit both `eu-strip` and `sepdebugcrcfix` are used in the LLDB testsuite only to workaround some DWZ bug it fails for some reason to process unsplit debug info. I did not find DWZ code convenient enough to bugfix it there and its author Jakub JelĂ­nek does not fix its reported bugs in recent years.

> The other thing that worries me is that your comments seem to indicate that not all dwz tests pass after this. Could you elaborate on the "Many ERRORs are correct" part and how you plan to rectify that?

There is never any Success->Failure case for _dwarf->_dwz (there were such cases when I had bugs in my LLDB DWZ code).  But there are Success->Error cases because in some cases DWZ tool cannot be used such as:

  os command: make MAKE_DSYM=NO DWZ=YES ARCH=x86_64 CC="/quad/home/jkratoch/redhat/llvm-git-build-release/bin/clang-6.0"
  with pid: 14709
  stderr: dwz: a.out.debug.dwz: .debug_info section not present
  make[4]: *** [../../make/Makefile.rules:538: a.out] Error 1
  retcode: 2
  Error when building test subject.

Unaware what to do with it. It could run the testcase without DWZ but then the _dwarf testcase would be needlessly run twice. Or there could be a list of tests to skip in DWZ mode. Or maybe some list of "ExpectedError" testcases (I guess one cannot defined "ExpectedError" now). This also means `make check-lldb` prints with DWZ a lot of error messages due to these "expected Errors".

> your comments seem to indicate that not all regular dwarf tests were passing for you to begin with. Is that true?

Yes, I haven't investigated why yet.  I am used from GDB to only diff results against regressions.  RESULT-clean/ <https://people.redhat.com/jkratoch/RESULT-clean/> or RESULT-clean.tar.xz <https://people.redhat.com/jkratoch/RESULT-clean.tar.xz>
BTW with installed system debug info files (`/usr/lib/debug/**.debug`) the LLDB testsuite times out and fails completely.  LLDB could have some option like: `gdb -iex 'set debug-file-directory /notexists'`

> Would you be willing to help me (probably in a separate thread) to identify the tests that are failing and why?

Yes but I would like to put more attention at the DWZ support upstreaming first as it is a LLDB blocker for Fedora/RHEL/CentOS.


More information about the lldb-commits mailing list