TTD code coverage time range filter

[NicoleFaye]

Added time range filter for ttd code coverage analysis.
Adjusted code coverage highlight alpha 1/4 -> 2/3
Fixed info log being incorrectly written to error stream for saving cached analysis results.
Added gitignore entries for windows build related artifacts

First time contributing to the repo. I vaguely understand there is an agreement i may need to sign if the code is accepted.

Let me know if there is anything i can do to improve this PR for future reference/contribution.

fixes #960 #966 #967 #968

[CLAassistant]

All committers have signed the CLA.

[xusheng6]

Hi @NicoleFaye , thanks a lot for the PR. This looks like a nice addition, I will review it when I can

[NicoleFaye]

upon further examination. it seems like it might be more appropriate to implement a call to
dx @$cursession.TTD.MemoryForPositionRange(startAddress, endAddress, "accessType", minPosition, maxPosition)

instead of manually filtering time positions on a generic memory query.

I can implement a change in logic, but wanted to add this comment before then.

My main concern with this possible change would be it's not generic enough to work with time travel debuggers other than windbg, I haven't looked too deeply at how the adapters work. or if this coverage analysis is specific to windbg.

[xusheng6]

upon further examination. it seems like it might be more appropriate to implement a call to dx @$cursession.TTD.MemoryForPositionRange(startAddress, endAddress, "accessType", minPosition, maxPosition)

instead of manually filtering time positions on a generic memory query.

I can implement a change in logic, but wanted to add this comment before then.

My main concern with this possible change would be it's not generic enough to work with time travel debuggers other than windbg, I haven't looked too deeply at how the adapters work. or if this coverage analysis is specific to windbg.

I think this is fantastic idea!

Also I would ask you to kindly test to make sure MemoryForPositionRange actually limits the query range rather than just filter it. The way to test is to get a reasonably large trace, and run the same query with and without a time range (ideally the time range is small). Expect the one with a time range runs much faster. Note you need to totally reset the debugger (close binja/windbg) because the query results are cached, and that would surely affect the accuracy of the comparison

Once you get that API, if you feel like to, you could also switch this dialog to use the new API:

You probably want to move the start/end address to the same line, and add a new start/end time beneath it

[xusheng6]

Please also create a separate issue to track the other enhancements made in this PR, which helps us better keep track of things!

[NicoleFaye]

Also I would ask you to kindly test to make sure MemoryForPositionRange actually limits the query range rather than just filter it. The way to test is to get a reasonably large trace, and run the same query with and without a time range (ideally the time range is small). Expect the one with a time range runs much faster. Note you need to totally reset the debugger (close binja/windbg) because the query results are cached, and that would surely affect the accuracy of the comparison

It indeed does. I just tested with a larger trace ~20gb, just as you described here.

[NicoleFaye]

I have implemented the call to MemoryForPositionRange in the dbgeng adapter and then added that call to the Code Coverage call in place of the filtering i originally implemented.

I am going to keep this PR as a draft until i can do a little more testing to make sure the ui parses correctly.

Then i will see about using this new api in the TTD memory query window as well. Once that has been completed i will take the PR out of draft to be reviewed. :)

[xusheng6]

Also I would ask you to kindly test to make sure MemoryForPositionRange actually limits the query range rather than just filter it. The way to test is to get a reasonably large trace, and run the same query with and without a time range (ideally the time range is small). Expect the one with a time range runs much faster. Note you need to totally reset the debugger (close binja/windbg) because the query results are cached, and that would surely affect the accuracy of the comparison

It indeed does. I just tested with a larger trace ~20gb, just as you described here.

That is fantastic!

[xusheng6]

I have implemented the call to MemoryForPositionRange in the dbgeng adapter and then added that call to the Code Coverage call in place of the filtering i originally implemented.

I am going to keep this PR as a draft until i can do a little more testing to make sure the ui parses correctly.

Then i will see about using this new api in the TTD memory query window as well. Once that has been completed i will take the PR out of draft to be reviewed. :)

Sounds good, please ping me when you are done with it!