This is an archive of the discontinued LLVM Phabricator instance.

Don't use lldb -O in lit tests
ClosedPublic

Authored by zturner on Nov 18 2018, 3:31 PM.

Details

Summary

Because of different shell quoting rules, and the fact that LLDB commands often contain spaces, -O is not portable for writing command lines. Instead, we should use explicit lldbinit files.

Diff Detail

Event Timeline

zturner created this revision.Nov 18 2018, 3:31 PM
davide requested changes to this revision.Nov 18 2018, 4:40 PM
davide added a subscriber: davide.

Is there a way of fixing this that doesn't require scattering the test between two files?

This revision now requires changes to proceed.Nov 18 2018, 4:40 PM

Is there a way of fixing this that doesn't require scattering the test between two files?

Unless we create a utility that extracts lines based on prefixes and outputs them to a temporary file, I don't have any great ideas.

FWIW I actually find it easier to read this way, the interaction between the various command line options makes it pretty confusing to follow the order in which the various commands are executed. combining -O, -o, -S, and -s makes it quite hard to figure out what commands are actually being executed and in what order.

Another advantage to having the commands be in their own file is that it's easy to reproduce the failure by just running lldb -s script.lldbinit.

I'd even go so far as to say that maybe the .test file should be the source code + check lines, and each of the 3 test cases should be a separate script file with all the commands together in one file. It could use the command source command to avoid duplication. So, for example, stop-hook-1.lldbinit could be something like:

target stop-hook add -f stop-hook.c -l 30 -e 34 -o "expr ptr"
command source stop-hook-common.lldbinit
friss added a comment.Nov 18 2018, 6:22 PM

I do agree it's slightly easier to read this way. I was conflicted while writing the tests between readability and conciseness. I think this is a good compromise.

I do prefer to have the check lines with the commands rather than with the source code though. The output is the result of the commands and sometimes it's not as clear what it refers to in the source.

davide accepted this revision.Nov 18 2018, 7:57 PM

I don't have any other great ideas either and I'd say the proposed alternative is not worth the complexity.

This revision is now accepted and ready to land.Nov 18 2018, 7:57 PM
This revision was automatically updated to reflect the committed changes.