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

Preparations to make RIOT 64-bit ready #20154

Closed
wants to merge 21 commits into from

Conversation

OlegHahm
Copy link
Member

@OlegHahm OlegHahm commented Dec 5, 2023

Adopted from #19890

Contribution description

Following @benpicco's proposal I handpicked the patches from #19890 that only prepare the code base for 64bit support.

All changes are done by @fzi-haxel.

Testing procedure

All tests and applications should remain unchanged for existing platforms.

@OlegHahm OlegHahm added Platform: native Platform: This PR/issue effects the native platform Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation labels Dec 5, 2023
@github-actions github-actions bot added Area: network Area: Networking Area: tests Area: tests and testing framework Area: core Area: RIOT kernel. Handle PRs marked with this with care! Area: pkg Area: External package ports Area: drivers Area: Device drivers Area: timers Area: timer subsystems Area: LoRa Area: LoRa radio support Area: OTA Area: Over-the-air updates Area: sys Area: System Area: examples Area: Example Applications Area: Kconfig Area: Kconfig integration and removed Platform: native Platform: This PR/issue effects the native platform labels Dec 5, 2023
@benpicco benpicco added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Dec 6, 2023
Copy link
Contributor

@benpicco benpicco left a comment

Choose a reason for hiding this comment

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

This all looks reassuringly straightforward!

pkg/flashdb/patches/0002-64bit-fix.patch Outdated Show resolved Hide resolved
#endif

-#if defined(__SIZEOF_INT128__) || ((__clang_major__ * 100 + __clang_minor__) >= 302)
+#if ((__clang_major__ * 100 + __clang_minor__) >= 302)
Copy link
Contributor

Choose a reason for hiding this comment

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

that one I don't understand

Copy link
Member Author

Choose a reason for hiding this comment

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

good question - @fzi-haxel?

Copy link
Contributor

Choose a reason for hiding this comment

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

On x86_64, __SIZEOF_INT128__ is defined, therefore __int128 is used, but this leads to this GCC warning:

build/pkg/micro-ecc/types.h:98:18: error: ISO C does not support ‘__int128’ types [-Werror=pedantic]
   98 | typedef unsigned __int128 uECC_dword_t;

In retrospect, simply not using __int128 does not seem to be the most elegant solution. Another option would be:

__extension__ typedef unsigned __int128 uECC_dword_t;

However, the GCC documentation points out the following when using __extension__

only system header files should use these escape routes.

What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm a bit confused: clang accepts __int128 even though it is not part of the C standard but gcc does not?

What I also do not understand: if __int128 is a built-in data type on gcc (>= 4.1) wouldn't I still get the warning even with the typedef? (Which definitiv would be actually used?)

Copy link
Contributor

Choose a reason for hiding this comment

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

If -Wpedantic is enabled, yes.
Example: https://godbolt.org/z/bsYq49jGY

Copy link
Contributor

Choose a reason for hiding this comment

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

Using __extension__ would get rid of the warning.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hm, actually, I tried this (using gcc 13.2.1) but still got the warning.

Copy link
Contributor

Choose a reason for hiding this comment

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

Are you sure? I just tested it with (13.2.0) and didn't get this warning.

But GCC 13 now gives this warning during linking

/usr/bin/ld: warning: /work/tests/pkg/micro-ecc/bin/native/cpu/tramp.o: missing .note.GNU-stack section implies executable stack

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, no, sorry, I think there was a PEBCAK issue (I always confuse the order of arguments for typedef).

Copy link
Contributor

Choose a reason for hiding this comment

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

Opened an issue upstream with some suggested solutions

-typedef int mp_int_t; // must be pointer size
-typedef unsigned mp_uint_t; // must be pointer size
+typedef intptr_t mp_int_t; // must be pointer size
+typedef uintptr_t mp_uint_t; // must be pointer size
Copy link
Contributor

Choose a reason for hiding this comment

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

Since we are using our own fork anyway, you might as well open the PR there.

Copy link
Member Author

@OlegHahm OlegHahm Dec 6, 2023

Choose a reason for hiding this comment

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

True - but actually unrelated to this PR, isn't it?

Sorry - got confused by the highlighting for the patch file here. I thought that was an actual diff instead of an added file.

Copy link
Member Author

Choose a reason for hiding this comment

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

Made a PR in the fork.

Copy link
Member Author

Choose a reason for hiding this comment

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

PR is merged, waiting for #20208 to get merged before we can drop this patch.

@riot-ci
Copy link

riot-ci commented Dec 6, 2023

Murdock results

FAILED

3d02eb6 Revert "examples/dtls-sock: Removed unnecessary FEATURES_REQUIRED"

Success Failures Total Runtime
5638 0 8098 07m:16s

Artifacts

@OlegHahm
Copy link
Member Author

OlegHahm commented Dec 7, 2023

Btw @fzi-haxel by no means I wanted to take over your contribution. I just got excited about your PR and the idea to have (finally) 64 bit support (for native) in RIOT and I thought that @benpicco had a good point that we could potentially speed up things by splitting the PR. Since the PR did seem stall somewhat, I just moved forward without asking you first. I hope that was okay with you!?

fzi-haxel and others added 12 commits December 21, 2023 17:30
Fixed compilation errors. Mostly DEBUG/printf formatting and void pointer casting.

Added another hardcoded offset for gnrc_sixlowpan_frag_* tests.
Increased mem size of lua test in case of 64 bit.
Reduced required backtrace size to 3 in native backtrace test.
Fix for failed murdock test
Additional bug found by compiling all tests with llvm.
Interestingly, this didn't crash the 64 bit tests before nor did it give a warning in GCC.
Added missing DOXYGEN documentation
@OlegHahm OlegHahm force-pushed the pr/64bit-preparation branch from a15c541 to 47ce2a2 Compare December 21, 2023 16:31
@github-actions github-actions bot removed the Area: OTA Area: Over-the-air updates label Dec 21, 2023
@OlegHahm
Copy link
Member Author

I rebased on current master (including @fzi-haxel's size_t formatters) and fixed the resulting merge conflicts.

@fzi-haxel
Copy link
Contributor

fzi-haxel commented Dec 21, 2023

I pushed three more PRs to Olegs branch:

  1. examples/dtls-sock: Revert changes due to separate PR
    Created examples/dtls-sock: Enable non 32-bit architectures #20196 as this is technically a general issue. It would be very helpful if someone with a compatible board could test it.
    (This should hopefully fix the murdock test)
  2. drivers: Missing size_t format specifiers
    I seem to have missed some size_t format specifiers in drivers that still use an unsigned cast in this PR.
  3. pkg: drop micropython patches
    Dropped micropython patches due to pkg: micropython: bump version #20208

Merge as you deem fit

@fzi-haxel
Copy link
Contributor

This should hopefully fix the murdock test

Or not...
I also re-ran native64 tests after the rebase and found even more problems.

I added a new PR and compiled all examples/tests for avr-rss2, iotlab-m3, sipeed-longan-nano-tft, esp32-wroom-32, native and "native64".

@fzi-haxel
Copy link
Contributor

I think this PR has become a bit complicated to review and is probably still a bit too big to be easily discussed. I believe the best way to proceed with the PR is to break it down into smaller PRs that can be merged step by step.
I updated #19890 to reflect the state of this discussion and marked it as WiP.

@OlegHahm
Copy link
Member Author

Probably you're right. Should I fix this one?

@fzi-haxel
Copy link
Contributor

Probably you're right. Should I fix this one?

All commits and review change requests in this PR should now be included in other smaller PRs.
The main PRs are

Therefore, I think you could close this PR.
Many thanks to the reviewers and especially to @OlegHahm for the effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: core Area: RIOT kernel. Handle PRs marked with this with care! Area: drivers Area: Device drivers Area: examples Area: Example Applications Area: Kconfig Area: Kconfig integration Area: LoRa Area: LoRa radio support Area: network Area: Networking Area: pkg Area: External package ports Area: sys Area: System Area: tests Area: tests and testing framework Area: timers Area: timer subsystems CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants