-
Notifications
You must be signed in to change notification settings - Fork 34
[ATfE] Enable v7-A and v7-R variants for LLVM-libc tests #486
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -35,8 +35,12 @@ void setup() { | |
| // The vector table is always at address 0. The inline assembly is needed | ||
| // here to hide the memcpy to a null pointer from the compiler. | ||
| void *final_vector_table = NULL; | ||
| asm("" : "+r"(final_vector_table)); | ||
| memcpy(final_vector_table, (void *)&vector_table, 64); | ||
| // Don't use memcpy as llvmlibc memcpy will fault a copy to address 0. | ||
| // Size is more important than speed here so don't unroll the loop. | ||
| _Pragma("clang loop unroll(disable) vectorize(disable)") for ( | ||
|
Comment on lines
+39
to
+40
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As far as I can tell,
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is to prevent an internal LLVM-libc issue (see line 38)
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, I mean the pragma to prevent loop unrolling. Since even
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh I see what you mean. Here I'm removing the call to |
||
| int i = 0; i < 64 / sizeof(unsigned int); i++) { | ||
| ((unsigned int *)final_vector_table)[i] = ((unsigned int *)vector_table)[i]; | ||
| } | ||
| #endif | ||
| } | ||
|
|
||
|
|
||
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.
Why the change in syntax here?
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.
Honestly most of the code should use this
[[c++11]]type syntax. It's more modern.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.
But this is C++ syntax then, not C.
I'm not against it, but we must be sure that this will be compatible with all configurations, especially with a C-only compilation.
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, this attribute syntax has been backported, at least on Clang. Also, this library is compiled on our systems, and this attribute will not affect user code at all, so as long as we don't use very old versions that are unsupported by Clang, we should be OK.
https://stackoverflow.com/questions/74574618/old-style-vs-c11-attribute-syntax