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

Thu Nov 30 06:57:14 PST 2017

labath added a comment.

In https://reviews.llvm.org/D40475#940226, @jankratochvil wrote:

> > 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? :-)

There aren't that many lldb developers... I wouldn't be surprised if the number of them having access to a red-hat machine is 1 (you).

> 
> 
>> 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.

It looks like it could be a fun project to reimplement `dwz` on top of llvm dwarf library, but I understand that would be a considerable detour for you.

> 
> 
>> 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".

How many tests are we talking about here? Could you list them here? If these really don't produce any debug info, then we can probably just mark them as `@no_debug_info_testcase` (that prevents generating N versions of the same test) and be done with it. There is also the ability to skip a test for dwz explicitly.

Also, be aware that we don't really do a good job of distinguising errors and failures. Compilation problems are a common source of Errors, but other issues can come up as errors as well -- it just depends on details of how test is written.

>> 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>

Yea, sometimes you have to do that here as well, but it's not a place where we'd like to be.
Looking at the results, they don't seem that bad, really. Most of the failures are in data formatters -- I think a well-placed `-fno-limit-debug-info` would get those working. The other category is something in the system library confusing the test (e.g. can't find `environ` or an extra global variable `c`). I think we could get those resolved fairly quickly.

BTW, is this on current master? I was hoping that some of these (such as TestTopLevelExpressions) would be resolved already.

> 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'`

Yea, that would be useful, particularly as we want to isolate the test from system specifics. It would also be useful to figure out why does it hang, as it will probably affect your users as well. :)

https://reviews.llvm.org/D40475