Skip to content
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

CMake test data files are not being properly built... #16

Closed
N3rdle opened this issue Apr 15, 2013 · 3 comments
Closed

CMake test data files are not being properly built... #16

N3rdle opened this issue Apr 15, 2013 · 3 comments

Comments

@N3rdle
Copy link

N3rdle commented Apr 15, 2013

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.

@pjbakker
Copy link
Contributor

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.

@N3rdle
Copy link
Author

N3rdle commented Apr 15, 2013

so they are. i read everything quite the inverse. i'm an idiot ;)

sorry!

@pjbakker
Copy link
Contributor

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 <Gilles.Peskine@arm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants