-
Notifications
You must be signed in to change notification settings - Fork 85
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 Z_FEATURE_ASSEMBLY_NOP #313
Conversation
Add Z_FEATURE_ASSEMBLY_NOP to allow the user to disable assembly nop code as it raises the following build failure on some "exotic" architectures such as or1k: /home/autobuild/autobuild/instance-1/output-1/build/libzenoh-pico-0.10.0-rc/src/link/endpoint.c: Assembler messages: /home/autobuild/autobuild/instance-1/output-1/build/libzenoh-pico-0.10.0-rc/src/link/endpoint.c:358: Error: unrecognized instruction `nop' Fixes: - http://autobuild.buildroot.org/results/fd0b2c666a1dc1537162d15b27743abd270243ed Signed-off-by: Fabrice Fontaine <[email protected]>
Though I understand the problem you encounter and that PR do solve it, I'd prefer trying to get rid of the So unless we don't find a way to do this, I vote for postponing this PR. |
I can update the PR to remove all |
I'll do it, I just need to check with the team if there was no particular reason we had to use the |
Great, thank you. I'll wait for your feedback before sending a patch to buildroot. |
As an alternative (since investigation reveals that the #ifndef _Z_ASM_NOP
#define _Z_ASM_NOP _asm_("nop")
#endif This would let us keep the current nops, be less verbose, keep the symbol private, and allow users to define the nop as something else if needed for their platform. |
@@ -361,7 +361,9 @@ | |||
if (_z_str_eq(proto, RAWETH_SCHEMA) == true) { | |||
len = _z_raweth_config_strlen(s); | |||
} else { | |||
#if Z_FEATURE_ASSEMBLY_NOP == 1 |
Check warning
Code scanning / Cppcheck (reported by Codacy)
misra violation 2009 with no text in the supplied rule-texts-file Warning
@@ -399,7 +401,9 @@ | |||
if (_z_str_eq(proto, RAWETH_SCHEMA) == true) { | |||
_z_raweth_config_to_str(s); | |||
} else { | |||
#if Z_FEATURE_ASSEMBLY_NOP == 1 |
Check warning
Code scanning / Cppcheck (reported by Codacy)
misra violation 2009 with no text in the supplied rule-texts-file Warning
@@ -32,7 +32,9 @@ | |||
uint8_t ret = 0; | |||
#if defined(ZENOH_LINUX) | |||
while (getrandom(&ret, sizeof(uint8_t), 0) <= 0) { | |||
#if Z_FEATURE_ASSEMBLY_NOP == 1 |
Check warning
Code scanning / Cppcheck (reported by Codacy)
misra violation 2009 with no text in the supplied rule-texts-file Warning
@@ -58,7 +62,9 @@ | |||
uint32_t ret = 0; | |||
#if defined(ZENOH_LINUX) | |||
while (getrandom(&ret, sizeof(uint32_t), 0) <= 0) { | |||
#if Z_FEATURE_ASSEMBLY_NOP == 1 |
Check warning
Code scanning / Cppcheck (reported by Codacy)
misra violation 2009 with no text in the supplied rule-texts-file Warning
@@ -85,7 +93,9 @@ | |||
void z_random_fill(void *buf, size_t len) { | |||
#if defined(ZENOH_LINUX) | |||
while (getrandom(buf, len, 0) <= 0) { | |||
#if Z_FEATURE_ASSEMBLY_NOP == 1 |
Check warning
Code scanning / Cppcheck (reported by Codacy)
misra violation 2009 with no text in the supplied rule-texts-file Warning
@@ -45,7 +47,9 @@ | |||
uint16_t ret = 0; | |||
#if defined(ZENOH_LINUX) | |||
while (getrandom(&ret, sizeof(uint16_t), 0) <= 0) { | |||
#if Z_FEATURE_ASSEMBLY_NOP == 1 |
Check warning
Code scanning / Cppcheck (reported by Codacy)
misra violation 2009 with no text in the supplied rule-texts-file Warning
@@ -71,7 +77,9 @@ | |||
uint64_t ret = 0; | |||
#if defined(ZENOH_LINUX) | |||
while (getrandom(&ret, sizeof(uint64_t), 0) <= 0) { | |||
#if Z_FEATURE_ASSEMBLY_NOP == 1 |
Check warning
Code scanning / Cppcheck (reported by Codacy)
misra violation 2009 with no text in the supplied rule-texts-file Warning
I think having |
That makes sense for the loops but some |
#314 has been merged. @ffontaine can you please check if the problem is fixed for you? |
Seems to work, I'll send a patch to buildroot, thanks |
Add
Z_FEATURE_ASSEMBLY_NOP
to allow the user to disable assemblynop
code as it raises the following build failure on some "exotic" architectures such as or1k:Fixes: