briansmith / ring

Safe, fast, small crypto using Rust

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

-Winline on ESPIDF

coder0xff opened this issue · comments

I'm trying to build for an esp32-series platform (os: espidf, arch: xtensa), and I get the following:

warning: ring@0.17.7: crypto/fipsmodule/aes/aes_nohw.c: In function ‘aes_nohw_transpose’:
warning: ring@0.17.7: crypto/fipsmodule/aes/aes_nohw.c:432:20: error: inlining failed in call to ‘aes_nohw_swap_bits’: call is unlikely and code size would grow [-Werror=inline]
warning: ring@0.17.7:   432 | static inline void aes_nohw_swap_bits(aes_word_t *a, aes_word_t *b,
warning: ring@0.17.7:       |                    ^~~~~~~~~~~~~~~~~~
warning: ring@0.17.7: crypto/fipsmodule/aes/aes_nohw.c:461:3: note: called from here
warning: ring@0.17.7:   461 |   aes_nohw_swap_bits(&batch->w[5], &batch->w[7], 0x33333333, 2);
warning: ring@0.17.7:       |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
warning: ring@0.17.7: crypto/fipsmodule/aes/aes_nohw.c:432:20: error: inlining failed in call to ‘aes_nohw_swap_bits’: call is unlikely and code size would grow [-Werror=inline]
warning: ring@0.17.7:   432 | static inline void aes_nohw_swap_bits(aes_word_t *a, aes_word_t *b,
warning: ring@0.17.7:       |                    ^~~~~~~~~~~~~~~~~~
warning: ring@0.17.7: crypto/fipsmodule/aes/aes_nohw.c:460:3: note: called from here
warning: ring@0.17.7:   460 |   aes_nohw_swap_bits(&batch->w[4], &batch->w[6], 0x33333333, 2);
warning: ring@0.17.7:       |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

and more, which are of course treated as errors due to -Wall. Builds for this platform tend to be optimized for size (-Os), and I suspect that's why the compiler is rejecting the inlining. Commenting out the -Winline in build.rs is enough to work around it, but that doesn't seem like a PR that would get accepted. I'm interested in submitting a PR for this issue, but I'm not sure of the best way to approach it. What do you recommend?

Do you have a way of measuring the performance for -Os an -O2/-O3 builds?

Probably the best solution is to have build.rs pass flags to the compiler that will allow the compiler to still emit the warnings but treat them was warnings instead of errors. IDK off the top of my head how to do that. Do you know?

Addressed in PR #1952.