-
Notifications
You must be signed in to change notification settings - Fork 157
A few SDK fixes from picolibc work #580
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
Closed
keith-packard
wants to merge
3
commits into
zephyrproject-rtos:main
from
keith-packard:keithp-sdk-fixes
Closed
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
@claziss could you please comment on the register used for bare-metal TLS implementation on both ARCv2 & ARCv3? To me it looks like it's
r25
at least on ARCv2.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.
The register number itself is fine (I guess), we use r26 in zephyr itself: https://github.com/zephyrproject-rtos/zephyr/blob/9331591ab1f6a59513ded32d877f62dbf4526b9e/arch/arc/CMakeLists.txt#L15-L20I
But I'm wondering if it is OK to
-mtp-regno=26
to the toolchain itself, given that we don't always use TLS in Zephyr.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.
@keith-packard should we specify
-mtp-regno=26
for picolibc only? we can make picolibc depend on TLS.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.
Hi, TLS is default off for baremetal apps as they need to provide an environment for make it to work. Now, one can enable it or, if it is enabled, change the thread pointer (TP) register number using
mtp-regno
option. By default TP is set to r25, and it should work for other values as well, but I haven't test that.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.
Hrm. Does the compiler reserve this register when specified like this so that other code doesn't use it? If so, then, yes, we need to specify this for the toolchain so that no other code built by the toolchain conflicts with potential TLS usage by Zephyr.
If the compiler doesn't reserve register 26, then does this parameter have any effect on code that doesn't use __thread variables? If not, then adding it unconditionally should not cause any issues.
In either case, I think we want to have the toolchain built with this parameter so that everything agrees on the TLS ABI.
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.
@evgeniy-paltsev sure, but can you please create a separate PR for this to
sdk-ng
andzephyr
since it is quite a major change and not really something for the SDK 0.15.2?@keith-packard That would come with some performance implications when TLS is not enabled; but, I assume such a performance impact would be small enough.
Given that it probably is not going to be worth building separate multilib variants for non-TLS and TLS, sure.
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.
This raises a good point -- we should stick the -mtp-regno parameter into the multilib configuration -- that way a conflicting value will cause link failures instead of silent corruption. And, any pieces of the toolchain using the multilib configs (like newlib, picolibc, libstdc++) will automatically get the correct value here. That seems like a good way to keep the toolchain os-independent and ensure that Zephyr uses will work correctly.
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.
and, of course, would allow us to build multilib configurations that use r25 or r26 even, if the Arc team wants to transition.
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.
Ideally yes, but ARC is one of the those platforms with already many multilib variants; adding r25 and r26 variants will multiply already many variants and significantly increase both the toolchain build time and size.
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.
I'm giving that a try to see how bad it gets. "only" multiplies the library builds for the toolchain by a factor of three ...