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 stdout: stderr: dwz: a.out.debug.dwz: .debug_info section not present make[4]: *** [../../make/Makefile.rules:538: a.out] Error 1 retcode: 2 ERROR 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. https://reviews.llvm.org/D40475 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
