This is an archive of the discontinued LLVM Phabricator instance.

Add verbose logging support to gdb-remote tests
ClosedPublic

Authored by labath on Feb 3 2016, 8:42 AM.

Details

Summary

gdb-remote tests are not able to use the same logging mechanisms as the rest of our tests, and
currently we get no host logs from them, even though the tests themselves have logging
capability. This commit changes that. When user specifies that he would like to log the
gdb-remote channel (--channel gdb-remote argument to dotest.py), we write detailed logs to the
<TEST_ID>-host.log file, just like we would in the case of regular tests. If this argument is not
specified, we only log the serious messages to stderr, which matches the existing behaviour.

Diff Detail

Repository
rL LLVM

Event Timeline

labath updated this revision to Diff 46795.Feb 3 2016, 8:42 AM
labath retitled this revision from to Add verbose logging support to gdb-remote tests.
labath updated this object.
labath added reviewers: tfiala, tberghammer.
labath added a subscriber: lldb-commits.
tfiala accepted this revision.Feb 3 2016, 9:06 AM
tfiala edited edge metadata.

LGTM.

BTW I was planning on re-organizing the lldb-server/debugserver tests sometime in the near future to break them into many different directories and pull off the dsym/dwarf/dwo changes for the many tests where that doesn't matter. It's causing more tests to run and is less concurrent than it could be with our test runner. I'll shoot out a note when that time shows up. (It may still be a while, feel free to tackle if you want to get there sooner.)

This revision is now accepted and ready to land.Feb 3 2016, 9:06 AM
This revision was automatically updated to reflect the committed changes.
labath added a comment.Feb 4 2016, 2:15 AM

BTW I was planning on re-organizing the lldb-server/debugserver tests sometime in the near future to break them into many different directories and pull off the dsym/dwarf/dwo changes for the many tests where that doesn't matter.

I think that basically none of these tests rely on debug info, and we can remove the debug info duplication entirely. Unfortunately, the only way right now is to annotate each function with @no_debug_info_test, so I have been waiting until I get a chance to make that decorator work on classes.

That should cut the running time in half, so then you may not even need to split stuff out more...

tfiala added a comment.Feb 4 2016, 7:13 PM

BTW I was planning on re-organizing the lldb-server/debugserver tests sometime in the near future to break them into many different directories and pull off the dsym/dwarf/dwo changes for the many tests where that doesn't matter.

I think that basically none of these tests rely on debug info, and we can remove the debug info duplication entirely. Unfortunately, the only way right now is to annotate each function with @no_debug_info_test, so I have been waiting until I get a chance to make that decorator work on classes.

That should cut the running time in half, so then you may not even need to split stuff out more...

True.

Maybe I'll wait until then. If/when I get to writing more tests in that area, I may reorganize just because it is currently a massive hunk of tests in one file, but if you're going to get rid of the alternatives with a class-level decorator, that definitely will remove the main piece I cared about (namely, the time).