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

native: 64-Bit support? #6603

Closed
brummer-simon opened this issue Feb 14, 2017 · 20 comments · May be fixed by #13009
Closed

native: 64-Bit support? #6603

brummer-simon opened this issue Feb 14, 2017 · 20 comments · May be fixed by #13009
Assignees
Labels
Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR Platform: native Platform: This PR/issue effects the native platform State: don't stale State: Tell state-bot to ignore this issue Type: new feature The issue requests / The PR implemements a new feature for RIOT

Comments

@brummer-simon
Copy link
Member

Hi,

I have read today that Arch Linux seems to discontinue x86 32-bit
platform support in summer 2017.

Other distributions might follow in the future. Are there any plans to
get rid of natives dependencies to its manditory 32-bit libraries?

@PeterKietzmann PeterKietzmann added Feature Request Type: question The issue poses a question regarding usage of RIOT labels Feb 14, 2017
@miri64
Copy link
Member

miri64 commented Feb 14, 2017

This doesn't make much sense IMHO. We don't have support for any other 32-bit platform.

@brummer-simon
Copy link
Member Author

brummer-simon commented Feb 15, 2017

@miri64 - I dont get what you mean. I am just saying that Linuxes support for i386 starts to vanish sooner or later, therfore "native" should buildable under Linux on x86_64 without dependencies to i386 libraries.

@kaspar030
Copy link
Contributor

@brummer-simon Arch only discuntinues 32bit only installations. they will not drop support for 32bit userland binaries.

Having native compile for 32bit would be nice-to-have, but IMHO is not worth the effort of fixing the codebase (yet).

@miri64
Copy link
Member

miri64 commented Feb 15, 2017

@brummer-simon

@miri64 - I dont get what you mean. I am just saying that Linuxes support for i386 starts to vanish sooner or later, therfore "native" should buildable under Linux on x86_64 without dependencies to i386 libraries.

I mean, why making the native platform vastly different, only because one distro is dropping toolchain support for it (which it isn't, see @kaspar030's comment). There are always ways to install software beyond the official repositories of a Linux distribution (in Arch even easier than most other distros IMHO), so why enforce a very different architecture (64bit on native vs (32bit, 16bit or 8bit) on all other platforms) just because you can't apt-get install gcc-multilib anymore?

@kaspar030

Having native compile for 32bit would be nice-to-have, but IMHO is not worth the effort of fixing the codebase (yet).

You mean 64bit?

@miri64
Copy link
Member

miri64 commented Feb 15, 2017

[…] just because you can't apt-get install gcc-multilib anymore?

I mean of course pacman -S gcc-multilib ^^"

@LudwigKnuepfer
Copy link
Member

LudwigKnuepfer commented Feb 25, 2017

| We don't have support for any other 32-bit platform.

You mean 64bit?

| Are there any plans to get rid of natives dependencies to its manditory 32-bit libraries?

Not that I'm aware of.

@LudwigKnuepfer
Copy link
Member

I highly doubt any major Linux distribution will drop 32-bit support (available via multilib for the x86_64 platform) in the foreseeable future.
That being said there are pros and cons.

Pro:

  • improve RIOT's code base by fixing 64 related errors
  • simplify toolchain setup for native

Con:

  • effort / gain (as it's unlikely we will support any other 64 bit platform, fixing potential 64 bit errors in RIOT is less beneficial)
  • decreased 32 bit testing (unless we make 32 the default in which case the toolchain setup argument is diminished)

From my perspective the pros don't justify pulling manpower from other tasks.

@LudwigKnuepfer
Copy link
Member

Closing as memo, reopen if you disagree.

@LudwigKnuepfer LudwigKnuepfer added the State: archived State: The PR has been archived for possible future re-adaptation label Feb 25, 2017
@LudwigKnuepfer
Copy link
Member

PS:
I added my answer to the FAQ - if I missed some important point please update there as well.

@miri64
Copy link
Member

miri64 commented Feb 27, 2017

We don't have support for any other 32-bit platform.

You mean 64bit?

Yes ^^"

@daid
Copy link

daid commented Jan 3, 2018

Just as an extra note on this issue: Installing "gcc-multilib" on debian jessie removes certain cross compilers. It's not uncommon to have cross compilers installed on embedded development environments.

daid@monolith:~/RIOT/examples/hello-world$ sudo apt-get install gcc-multilib
[sudo] password for daid:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
crossbuild-essential-armhf g++-4.9-arm-linux-gnueabihf g++-arm-linux-gnueabihf gcc-4.9-arm-linux-gnueabihf gcc-arm-linux-gnueabihf

If support for 16bit and 8bit architectures is already there, then it feels odd to say: But 64bit is too much effort without gain. Any 32->64bit bug you will have is a hidden bug for 32->16/8bit, effecting most likely performance/memory usage.

@miri64 miri64 added the Type: new feature The issue requests / The PR implemements a new feature for RIOT label Sep 30, 2018
@miri64
Copy link
Member

miri64 commented Nov 14, 2019

From #6603 (comment)

I highly doubt any major Linux distribution will drop 32-bit support (available via multilib for the x86_64 platform) in the foreseeable future.

Apparently this is now happening (spearheaded by Ubuntu):

So I think we need to re-open this discussion. #10121 is also related.

* decreased 32 bit testing (unless we make 32 the default in which case the toolchain setup argument is diminished)

We wouldn't have to. We could have basically three "boards": native32 (equivalent to the current native board), native64 (native with 64-bit support) and native (which is an alias for the version most suitable for the platform it is running on). For testing we could still run native32 (if we find a container it can run in).

@miri64 miri64 reopened this Nov 14, 2019
@miri64 miri64 added Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR Platform: native Platform: This PR/issue effects the native platform and removed State: archived State: The PR has been archived for possible future re-adaptation Type: question The issue poses a question regarding usage of RIOT labels Nov 14, 2019
@miri64 miri64 assigned x3ro and unassigned LudwigKnuepfer Dec 3, 2019
@miri64
Copy link
Member

miri64 commented Dec 3, 2019

I've heard rumors that @x3ro is working on native64, so I'm assigning him to this issue.

@miri64
Copy link
Member

miri64 commented Dec 3, 2019

@x3ro did you have a look at #6603 (comment)?

@x3ro
Copy link
Member

x3ro commented Dec 5, 2019

I have now 😅 So yeah, I started working on this, I think it was beginning of this year, and did get it to compile on Linux 64-bit, but was then scared off by debugger segfaults that I didn't care to debug 🤷‍♂ I might have some time to look into this later this month, potentially also at 36C3, but at this point I can't promise much. I'll try to attend the January Hack'n'Ack though.

@x3ro
Copy link
Member

x3ro commented Dec 16, 2019

I've started a branch over at https://github.com/x3ro/RIOT/tree/x64 – I've been focussing only on Intel/Linux x64 for now. It currently segfaults because the context switching assembly is still broken, but I have a rough idea what needs to be done. But if you ignore this, it does compile and run the hello world example on 64-bit native :D

@stale
Copy link

stale bot commented Jun 18, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Jun 18, 2020
@miri64 miri64 added the State: don't stale State: Tell state-bot to ignore this issue label Jun 18, 2020
@stale stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Jun 18, 2020
@miri64 miri64 added this to the Release 2020.07 milestone Jul 2, 2020
@MrKevinWeiss MrKevinWeiss removed this from the Release 2021.07 milestone Jul 15, 2021
@InspireSemi
Copy link

Any update on adding support for 64 bit.. I really think RIOT will quickly be left behind if this is not done.

@chrysn
Copy link
Member

chrysn commented Mar 16, 2024

We now do have a native64 board; was anything from this issue left unaddressed?

@maribu
Copy link
Member

maribu commented May 2, 2024

Fixed by #20315

@maribu maribu closed this as completed May 2, 2024
@maribu maribu changed the title native: 64 Bit support ? native: 64-Bit support? May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR Platform: native Platform: This PR/issue effects the native platform State: don't stale State: Tell state-bot to ignore this issue Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging a pull request may close this issue.