CMake test data files are not being properly built... #16
Comments
|
Hi, The .data files are not meant to be generated. They are the basis from which the test_suite_xxx.c files are generated. So if you delete the .data files, then there will be no test files. |
|
so they are. i read everything quite the inverse. i'm an idiot ;) sorry! |
|
No worries! Mistakes are part of being human ;) |
gilles-peskine-arm
added a commit
to gilles-peskine-arm/mbedtls
that referenced
this issue
Sep 5, 2017
…-of-programs Disable build of the programs in the toplevel makefile
hanno-becker
pushed a commit
to hanno-becker/mbedtls
that referenced
this issue
Jan 25, 2019
…dles-api Support for slots to handles crypto API changes under SPM
gilles-peskine-arm
added a commit
to gilles-peskine-arm/mbedtls
that referenced
this issue
Apr 16, 2021
Use bitwise or on the absolute values, rather than addition, to
combine a high-level error code with a low-level error code (or an
error code of either kind with 0). This gives the same result when
combining error codes of different levels, since those use disjoint
bit positions.
An advantage of using bitwise or is that it is more robust to
mistakes. For example, combining an error code with itself is now a
no-op. Combining two error codes from the same module is more likely
to result in an error code from that module. We detect such errors
dynamically in tests when MBEDTLS_TEST_HOOKS is enabled, but that
doesn't help for rare cases which are not covered by our tests.
Another advantage is that it guarantees that the result cannot be 0 if
either input is nonzero. This sometimes helps optimizers and static
analyzers.
A downside is that the generated code tends to be slightly larger. When
combining a high-level constant with a low-level value, which is a
common idiom, the typical cost with Arm Thumb seems to be 1 extra
instruction, e.g. dhm_read_bignum before:
30: 4b04 ldr r3, [pc, Mbed-TLS#16] ; (44 <dhm_read_bignum+0x44>)
32: 18c0 adds r0, r0, r3
44: ffffcf00 .word 0xffffcf00
After:
30: 23c4 movs r3, Mbed-TLS#196 ; 0xc4
32: 4240 negs r0, r0
34: 019b lsls r3, r3, Mbed-TLS#6
36: 4318 orrs r0, r3
38: 4240 negs r0, r0
Signed-off-by: Gilles Peskine <[email protected]>
McuxCIBot
pushed a commit
to nxp-mcuxpresso/mbedtls
that referenced
this issue
Nov 29, 2024
…les to its own repo Merge in MCUCORE/mcu-sdk-mbedtls from MCUX-56689-multirepo-mbedtls-migration to master * commit '4ab993747cf332b6c4be7a0b8798795d0859ab56': [MCUX-56689] Migrate mbedtls ymls and examples to its own repo
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
if we check out the current 1.2 branch code (1.2.7 as of today) from scratch and attempt to build, all the .data files that are automatically being generated to prepare for the test cases do not ever get created. i had another previously checked out branch that had the files generated already, and all the tests passed fine with those, but once i cleaned them up, they were never re-generated.
i have examined the methodology and don't see anything obvious, but am guessing the person who made the changes for test cases will know exactly what the issue is.
The text was updated successfully, but these errors were encountered: