-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add conditional dependency to tests #2231
Add conditional dependency to tests #2231
Conversation
Add a way to check compile time defionitions values, for determining whether to skip tests.
@@ -339,6 +339,7 @@ RSA Check Public key #5 (N smaller than 128 bits) | |||
mbedtls_rsa_check_pubkey:16:"7edcba9876543210deadbeefcafe4321":16:"3":MBEDTLS_ERR_RSA_KEY_CHECK_FAILED | |||
|
|||
RSA Check Public key #6 (N exactly 8192 bits) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this test pass when MBEDTLS_MPI_MAX_SIZE
is 1024?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes. Obviously, I can't test it on target, because with MBEDTLS_MPI_MAX_SIZE
of 1024, we get stack overflow, but on PC, tests pass
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isnt it possible to simply increase the stack size to a suitable value if the test is really needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is a reasonable solution. Since we would like to test as closely to real use case.
Nonetheless, we still want to run this test ( N exactly 8192 bits) only when MBEDTLS_MPI_MAX_SIZE
is >=
1024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is a reasonable solution. Since we would like to test as closely to real use case.
Why not? A higher value is not an "unrealistic" situation, its probably just uncommon in the embedded setting. In any case, I would expect at least some of our tests to require slightly higher stack size for one or another reason...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we should get some feedback from the tests if we increase the stack consumption of a function. But that's more complex than a pass/fail unless we define some hard targets. Using a realistic stack size gives us a pass/fail result about stack consumption, but also means that we have to exclude some tests. I'd rather include as many tests as possible and use a larger-than-usual stack size. If we want feedback about stack usage we should get it as a metric with some instrumentation to determine peak stack usage for each test case, not as pass/fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In any case, we should skip some tests in some cases, when users change the default configuration
tests/scripts/generate_test_code.py
Outdated
@@ -731,18 +732,19 @@ def gen_dep_check(dep_id, dep): | |||
raise GeneratorInputError("Dependency Id should be a positive " | |||
"integer.") | |||
_not, dep = ('!', dep[1:]) if dep[0] == '!' else ('', dep) | |||
_defined = '' if re.search(r'(<=?|>=?|==)', dep) else 'defined' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we tested with ==
? Like, depends_on:MBEDTLS_MPI_MAX_SIZE==1024
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested the regular expressions in a python shell:
>>> pattern=r'(<=?|>=?|==)'
>>> def pat_search():
... if re.search(pattern, dep):
... return ''
... else:
... return 'defined'
>> dep='ABC>=123'
>>> print pat_search()
>>> dep='ABC==123'
>>> print pat_search()
>>> dep='ABC>123'
>>> print pat_search()
>>> dep='ABC=123'
>>> dep='ABC<=123'
>>> print pat_search()
>>> dep='ABC=123'
>>> print pat_search()
defined
tests/scripts/generate_test_code.py
Outdated
@@ -184,7 +184,7 @@ | |||
END_CASE_REGEX = r'/\*\s*END_CASE\s*\*/' | |||
|
|||
DEPENDENCY_REGEX = r'depends_on:(?P<dependencies>.*)' | |||
C_IDENTIFIER_REGEX = r'!?[a-z_][a-z0-9_]*$' | |||
C_IDENTIFIER_REGEX = r'!?[a-z_][a-z0-9_]*(([<>]=?|==)[0-9]*)?$' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please keep C_IDENTIFIER_REGEX
the way it was and define a new macro for an identifier with a numerical constraint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, but it is used only in validate_dependency()
, and there the numerical constraint is also sent to be validated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I suggested is to remove validate_dependency
. Let the C preprocessor handle the job.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is always best to catch problems as early as possible. in this case, in the python script, and not during compile time.
If one has a typo causing an invalid dependency, I would expect it to be raised while generating the tests, and not during compile time, or worse, on runtime, because any character works
Seperate the REGEX into identifier, condition and value, into groups, to behandled differently.
2ef7214
to
b9b3813
Compare
@gilles-peskine-arm I have modified according to your comment, although I think that in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved. I question the restriction that guards to be of the form <identifier> <relation-operation> <numerical-value>
: I think we should allow arbitrary guards and let the C preprocessor validate them. However such guards are what we need most urgently, so I'm ok with going with them for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
CI passed with exception of FreeBSD timing test. That's as good as a pass. |
Can you backport this please @RonEld? |
@sbutcher-arm I have asked @dgreen-arm to integrate this PR into #2075 as this PR modifies a file that doesn't exist yet in |
I have backported it though to |
Okay, I understand. This is a feature that fixes an issue, dependent on another test feature that hasn't yet been back ported. I think that shouldn't hold up merging. |
Description
Some tests can run only if some compile time definitions meet a certain condition. For example, 8192 bit rsa key tests should not run if
MBEDTLS_MPI_MAX_SIZE
is less than 1024.This PR adds a way to check compile time definitions values, for determining
whether to skip tests.
Status
READY
Requires Backporting
This is an enhancemnet, but to hte test infrastructure, so we may consider backporting this
Additional comments
Tested on Linux and K64F
Todos
Steps to test or reproduce
Set
MBEDTLS_MPI_MAX_SIZE
to 512, and runtest_suite_rsa
. The test "RSA Check Public key #6 (N exactly 8192 bits)" should be skipped