Add a few more lit tests

[cjappl]

These tests:

1. Test continue mode
2. Ensure that each of the attributes work with/without linking the sanitizer library
3. Ensure nosanitize works outside the [[realtime]] block

Just some basic sanity checks to make sure we don't regress! Please double check that we like the test file names

[davidtrevelyan]

Should we try to get the executable to exit with a nonzero return code if RADSan has detected an error in continue mode? One idea - I guess it might be possible to put some sort of class instance in the RADSan library that:

1. has lifetime beyond main,
2. maintains an atomic bool for whether RADSan ever detected a violation or not, and
3. calls exit(EXIT_FAILURE) in its destructor.

Alternative idea: we could put some checking function into the .fini_array, to be called after main, just like we insert some interceptor setup logic into the .preinit_array (which is called before main). This checking function could exit(EXIT_FAILURE) if RADSan ever errored in continue mode!

[cjappl]

Yep! You got the general sketch totally right. There is a lot of good examples of how the other sanitizers do this, and you'll see the base of it put down in this upcoming review for the flags.

[davidtrevelyan]

Cool, so should I wait for the next PR and resolve this comment thread for now?

[cjappl]

yep. It won't even be entirely fixed in that review, as to do "one thing per review" but you'll at least see the direction it's going.

The fix for it is a little involved, so I want to make sure these PRs stay focused on one task at a time. I'm hot on the trail though, and won't let this comment/problem linger for long.

[davidtrevelyan]

Nice additions, @cjappl. These look like great high-level safety nets. I have a couple of general comments:

1. (This one might need a bit of explaining!) I think the concept of whether or not the executable is "linked" to the radsan runtime library should be "private" to the implementation of the sanitizer. Really the user shouldn't need to know about the library and whether it's linked - at all! All the user should care about is whether realtime sanitizer is active or inactive, controlled by the -fsanitize=realtime flag. I don't think we need to make any code changes - so why do I mention this? I'm just bringing this up in the context of naming the test files - I see that a few are named things like "not_linking". I think it would be easier to understand if it had a more user-focused name, like "radsan_inactive" or something.
2. I don't personally find the lit syntax particularly easy to understand. We also don't really want the test files to have super long descriptive names, like we might want for a unit test function name. So - how about we add a short comment to the top of each radsan lit test that just explains why it's there and what the test expects to happen? That way we don't necessarily have to worry so much about the test file name being perfect, either...

[cjappl]

Nice additions, @cjappl. These look like great high-level safety nets. I have a couple of general comments:

1. (This one might need a bit of explaining!) I think the concept of whether or not the executable is "linked" to the radsan runtime library should be "private" to the implementation of the sanitizer. Really the user shouldn't need to know about the library and whether it's linked - at all! All the user should care about is whether realtime sanitizer is active or inactive, controlled by the `-fsanitize=realtime` flag. I don't think we need to make any code changes - so why do I mention this? I'm just bringing this up in the context of naming the test files - I see that a few are named things like "__not_linking__". I think it would be easier to understand if it had a more user-focused name, like "__radsan_inactive__" or something.

2. I don't personally find the lit syntax particularly easy to understand. We also don't really want the test files to have super long descriptive names, like we might want for a unit test function name. So - how about we add a short comment to the top of each radsan lit test that just explains why it's there and what the test expects to happen? That way we don't necessarily have to worry so much about the test file name being perfect, either...

all this works for me. Doing a revision now