[Lldb-commits] [PATCH] D39315: Correct the start address for exported windows functions in arm

[Stephane Sezer via Phabricator via lldb-commits]

sas added a subscriber: fjricci.
sas added a comment.

In https://reviews.llvm.org/D39315#908284, @zturner wrote:

> So when you're using ds2 as the remote, are you still using the normal lldb test suite?  `dotest.py`?  If so, then we could have a test decorator that says `@expectedFailure(not(debugserver=ds2))` or something.  Then, even though you're the only one that can run it, at least YOU are sure it works.  Some coverage is better than nothing.  Is something like this possible?


So there are two ways we test our stuff.

First part is centered around ds2 testing, and you can see it here: https://travis-ci.org/facebook/ds2/builds/292216534. We build ds2 for a bunch of different targets, and for some of them, we run `dotest.py` with `LLDB_DEBUGSERVER_PATH=/path/to/ds2`. This gives us a lot of coverage for non-Windows targets.

For Windows targets, we can only build ds2 (see https://ci.appveyor.com/project/a20012251/ds2/branch/master) and we are unable to run tests because we need a binary of lldb for Windows, but the builds available on http://releases.llvm.org/ were historically broken, and when @fjricci tried to fix them it didn't lead anywhere IIRC.

The second way we have to test our debugging tools is to simply run our debugging scripts with a known target, internally. That doesn't use `dotest.py`. It simply launches lldb and ds2, tries to set breakpoints, control the execution of the process, etc. The changes I am currently sending upstream work with that type of internal testing, but that's of no use for you because you can't run it yourself, nor can you see the results of our runs. :/


https://reviews.llvm.org/D39315