Skip to content
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

include: Fix macros in order to facilitate running apps on AArch64 #21

Closed
wants to merge 2 commits into from

Conversation

mariasfiraiala
Copy link
Contributor

@mariasfiraiala mariasfiraiala commented Aug 3, 2022

This PR fixes multiple issues regarding newlib support on AArch64.

Signed-off-by: Maria Sfiraiala [email protected]
Signed-off-by: Eduard Vintilă [email protected]

@mariasfiraiala mariasfiraiala changed the title /include: Fix macros in order to facilitate running apps on AArch64 include: Fix macros in order to facilitate running apps on AArch64 Aug 3, 2022
@razvand razvand self-assigned this Aug 4, 2022
Copy link
Contributor

@razvand razvand left a comment

Choose a reason for hiding this comment

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

Hi, @mariasfiraiala , nice work figuring out the issues. See my comments.

include/fcntl.h Outdated Show resolved Hide resolved
@mariasfiraiala mariasfiraiala force-pushed the fix-aarch64 branch 2 times, most recently from 6a40566 to 8aaa74d Compare August 4, 2022 16:54
@mogasergiu
Copy link
Member

Can confirm this fixes the issue for me as well.

@razvand razvand added this to the v0.11.0 (Janus) milestone Aug 20, 2022
@razvand razvand added bug Something isn't working enhancement New feature or request labels Aug 20, 2022
Default size of the data model for AArch64 is 8 (64 bits) for long
types, however newlibc ends up defining LONG_MAX as 32 bits.

This issue causes extremely optimized functions, such as memchr (which
parses DTB for apps like SQLite or redis), to crash when compiled for
AArch64.

This commit redefines the size for long types as 64 bits on AArch64.

Signed-off-by: Maria Sfiraiala <[email protected]>
Copy link
Member

@mogasergiu mogasergiu left a comment

Choose a reason for hiding this comment

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

Might be worth adding a Fixes tag here:
Fixes: 58f9f3a3f7b5 ("include/fcntl.h: Replace O_NONBLOCK with new one on arm")

@mariasfiraiala
Copy link
Contributor Author

Might be worth adding a Fixes tag here: Fixes: 58f9f3a3f7b5 ("include/fcntl.h: Replace O_NONBLOCK with new one on arm")

Great suggestion, will do!

Copy link
Member

@mogasergiu mogasergiu left a comment

Choose a reason for hiding this comment

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

Reviewed-by: Sergiu Moga [email protected]

Previous fix regarding confusion between O_NONBLOCK and O_DIRECTORY
values changed O_NONBLOCK to a different number, therefore it drifted
away from FNONBLOCK (for which it was an alias) and caused a blocking
socket.

This commit simply changes the value of O_DIRECTORY, without being
necessary to redefine O_NONBLOCK or FNONBLOCK.

Fixes: 58f9f3a ("include/fcntl.h: Replace O_NONBLOCK with new one
on arm")

Signed-off-by: Maria Sfiraiala <[email protected]>
@mariasfiraiala
Copy link
Contributor Author

mariasfiraiala commented Oct 22, 2022

@skuenzer I've found a value for O_DIRECTORY that should fit our purpose: 0400000000 = 0x4000000. I've checked and has only one bit set, fits in int (used for the open function) and wasn't already used in _default_fcntl.h or fcntl.h.

Hope you find it satisfactory as well.

Copy link
Member

@mogasergiu mogasergiu left a comment

Choose a reason for hiding this comment

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

There don't seem to be any other conflicts, I did not pay that much attention last time - my apologies. I checked with some printf's inside sys_open()'s code and the flag seems to be correctly set and execution does land where I expected it to.

Reviewed-by: Sergiu Moga [email protected]

Copy link
Member

@skuenzer skuenzer left a comment

Choose a reason for hiding this comment

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

Thanks a lot for your investigation. The changes look good!

Reviewed-by: Simon Kuenzer [email protected]

Copy link
Contributor

@razvand razvand left a comment

Choose a reason for hiding this comment

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

Thanks, @mariasfiraiala

Reviewed-by: Razvan Deaconescu [email protected]
Approved-by: Razvan Deaconescu [email protected]

unikraft-bot pushed a commit that referenced this pull request Nov 16, 2022
Previous fix regarding confusion between O_NONBLOCK and O_DIRECTORY
values changed O_NONBLOCK to a different number, therefore it drifted
away from FNONBLOCK (for which it was an alias) and caused a blocking
socket.

This commit simply changes the value of O_DIRECTORY, without being
necessary to redefine O_NONBLOCK or FNONBLOCK.

Fixes: 58f9f3a ("include/fcntl.h: Replace O_NONBLOCK with new one
on arm")

Signed-off-by: Maria Sfiraiala <[email protected]>
Reviewed-by: Sergiu Moga <[email protected]>
Reviewed-by: Simon Kuenzer <[email protected]>
Reviewed-by: Razvan Deaconescu <[email protected]>
Approved-by: Razvan Deaconescu <[email protected]>
Tested-by: Unikraft CI <[email protected]>
GitHub-Closes: #21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working ci/merged enhancement New feature or request
Projects
Status: Done!
5 participants