Skip to content

Conversation

@saturn691
Copy link
Contributor

Support added in llvm/llvm-project#153576

Also update bootcode to support v7-A/v7-R outside of hermetic tests.

@saturn691 saturn691 requested a review from a team as a code owner August 14, 2025 13:46
// The table may also be relocated, so we make it position-independent by
// having a table of handler addresses and loading the address to pc.
__attribute__((naked, section(".vectors"), aligned(32))) void vector_table() {
[[gnu::section(".vectors"), gnu::aligned(32), gnu::used, gnu::naked,
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

Comment on lines +39 to +40
// Size is more important than speed here so don't unroll the loop.
_Pragma("clang loop unroll(disable) vectorize(disable)") for (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell, memcpy itself has unrolled loops, so I think you shouldn't worry about it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to prevent an internal LLVM-libc issue (see line 38)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I mean the pragma to prevent loop unrolling. Since even memcpy itself uses unrolling, having this pragma here is unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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 memcpy and using a manual copy.

@saturn691 saturn691 requested a review from vhscampos August 15, 2025 11:07
@saturn691 saturn691 merged commit 90b921c into arm:arm-software Aug 15, 2025
2 checks passed
@saturn691 saturn691 deleted the libc-enable-v7a+r branch August 15, 2025 15:40
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

Successfully merging this pull request may close these issues.

2 participants