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

Compatibility with the ARM architecture #8396

Merged
merged 19 commits into from
Jan 27, 2021
Merged

Compatibility with the ARM architecture #8396

merged 19 commits into from
Jan 27, 2021

Conversation

RiccardoM
Copy link
Contributor

@RiccardoM RiccardoM commented Jan 20, 2021

Description

This PR adds the compatibility with the ARM architecture, by casting math.MaxInt64, math.MaxUint32 and math.MaxUint64 to uint64, uint32 and uint64 respectively.

It also adds a series of tests to make sure that the build is successful on a list of common platforms (386, arm, arm64 and amd64).

The aim of this PR is to make the Cosmos SDK compatible with the ARM architecture. This is often used in single board computers like the Raspberry, which are often used by hobbyists to experiment with projects. By making the Cosmos SDK ARM-compatible, we could allow such people to get started with it by running a node on their Raspberry before moving to a safer environment.

Also, this might be particularly useful to all the Cosmos SDK-based projects that are currently running a testnet and would like to give their validators the opportunity to run a node in-house on the above-mentioned boards.


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

This PR adds the compatibility with the ARM architecture, by casting math.MaxInt64, math.MaxUint32 and math.MaxUint64 to uint64, uint32 and uint64 respectively.
x/ibc/testing/chain.go Outdated Show resolved Hide resolved
.github/workflows/test.yml Outdated Show resolved Hide resolved
.github/workflows/test.yml Outdated Show resolved Hide resolved
Co-authored-by: Alessio Treglia <quadrispro@ubuntu.com>
baseapp/options.go Outdated Show resolved Hide resolved
store/rootmulti/store.go Outdated Show resolved Hide resolved
store/rootmulti/store.go Outdated Show resolved Hide resolved
RiccardoM and others added 3 commits January 20, 2021 15:09
Co-authored-by: Alessio Treglia <quadrispro@ubuntu.com>
Co-authored-by: Alessio Treglia <quadrispro@ubuntu.com>
Co-authored-by: Alessio Treglia <quadrispro@ubuntu.com>
@alessio
Copy link
Contributor

alessio commented Jan 20, 2021

Why are you casting math.MaxInt64 to uint64 (unsigned)?

@RiccardoM
Copy link
Contributor Author

Why are you casting math.MaxInt64 to uint64 (unsigned)?

Cause the left side of the comparison is an uint64, so I figured out that was the correct type to have. Also, since math.MaxInt64 < math.MaxUint64, I thought that conversion would never give any problem

@alessio
Copy link
Contributor

alessio commented Jan 20, 2021

since math.MaxInt64 < math.MaxUint64, I thought that conversion would never give any problem

You need to cast to ensure it won't ever be a problem. However, what exactly is the problem you're trying to solve here? Does the compiler emit warnings/errors when building for arm64? And if, so can you post the buildlog please?

@RiccardoM
Copy link
Contributor Author

since math.MaxInt64 < math.MaxUint64, I thought that conversion would never give any problem

You need to cast to ensure it won't ever be a problem. However, what exactly is the problem you're trying to solve here? Does the compiler emit warnings/errors when building for arm64? And if, so can you post the buildlog please?

This is only the first error that raises. Once you solve that, you get similar ones for the rest of the cases I have fixed:

$ GOOS=linux GOARCH=arm LEDGER_ENABLED=false make build
make[1]: Entering directory '/sda1/Coding/Cosmos/Cosmos-SDK'
go build -mod=readonly -tags "netgo" -ldflags '-X github.com/cosmos/cosmos-sdk/version.Name=sim -X github.com/cosmos/cosmos-sdk/version.AppName=simd -X github.com/cosmos/cosmos-sdk/version.Version=goz-phase-1-1151-g3d2896a2e -X github.com/cosmos/cosmos-sdk/version.Commit=3d2896a2e43eeb8ad9d157ab12c13936a54cd906 -X "github.com/cosmos/cosmos-sdk/version.BuildTags=netgo," -w -s' -trimpath -o /sda1/Coding/Cosmos/Cosmos-SDK/build/ ./...
# github.com/cosmos/cosmos-sdk/store/rootmulti
store/rootmulti/store.go:716:4: constant 9223372036854775807 overflows int
make[1]: *** [Makefile:110: build] Error 2

store/rootmulti/store.go Outdated Show resolved Hide resolved
alessio and others added 4 commits January 20, 2021 16:29
Makefile Outdated Show resolved Hide resolved
Makefile Outdated Show resolved Hide resolved
@codecov
Copy link

codecov bot commented Jan 27, 2021

Codecov Report

Merging #8396 (6decdaf) into master (fd04f41) will not change coverage.
The diff coverage is 75.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #8396   +/-   ##
=======================================
  Coverage   61.47%   61.47%           
=======================================
  Files         630      630           
  Lines       36398    36398           
=======================================
  Hits        22377    22377           
  Misses      11671    11671           
  Partials     2350     2350           
Impacted Files Coverage Δ
store/rootmulti/store.go 66.05% <0.00%> (ø)
snapshots/store.go 74.31% <100.00%> (ø)
x/ibc/applications/transfer/module.go 60.68% <100.00%> (ø)
x/ibc/core/02-client/types/client.go 72.22% <100.00%> (ø)

.github/workflows/test.yml Outdated Show resolved Hide resolved
@alessio alessio merged commit e2f510a into cosmos:master Jan 27, 2021
alessio pushed a commit that referenced this pull request Jan 27, 2021
From: #8396
Thanks: @RiccardoM for the original patch.
@RiccardoM RiccardoM deleted the arm-compilation branch January 27, 2021 11:27
Copy link
Collaborator

@odeke-em odeke-em left a comment

Choose a reason for hiding this comment

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

Howdy @RiccardoM, thank you for this change! I have a question about what looks likes now an increase for height, which I believe would involve security changes and perhaps would first go through a design change; this change is related to casting but not changing limits of values; we also need a test to prevent such regressions.

@@ -711,9 +711,9 @@ func (rs *Store) Restore(
if height == 0 {
return sdkerrors.Wrap(sdkerrors.ErrLogic, "cannot restore snapshot at height 0")
}
if height > math.MaxInt64 {
if height > uint64(math.MaxUint64) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh oh, now height can be more than math.MaxInt64 aka >9223372036854775808, up until (1<<64 - 1) aka 18446744073709551615. That seems like a breaking change that's not related to ARM compatibility. The error message doesn't even match this check, plus I don't think there was a test to prevent such a regression. Please advise or revert this check.

Copy link
Contributor Author

@RiccardoM RiccardoM Jan 28, 2021

Choose a reason for hiding this comment

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

This was changed here by @alessio. I think he should be able to answer this better. The commit was b34e327

Copy link
Contributor

Choose a reason for hiding this comment

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

This should fix it #8466 - @odeke-em

alessio pushed a commit that referenced this pull request Jan 28, 2021
mergify bot added a commit that referenced this pull request Jan 29, 2021
See #8396 (comment)

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
alessio pushed a commit that referenced this pull request Feb 1, 2021
@clevinson clevinson mentioned this pull request Feb 10, 2021
23 tasks
alessio pushed a commit that referenced this pull request Feb 17, 2021
store/multistore: revert a height limit increase from #8396

See #8396 (comment)
alessio pushed a commit that referenced this pull request Feb 17, 2021
daeMOn63 pushed a commit to fetchai/cosmos-sdk that referenced this pull request Aug 19, 2021
See cosmos/cosmos-sdk#8396 (comment)

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
daeMOn63 pushed a commit to fetchai/cosmos-sdk that referenced this pull request Aug 20, 2021
See cosmos/cosmos-sdk#8396 (comment)

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
daeMOn63 pushed a commit to fetchai/cosmos-sdk that referenced this pull request Mar 1, 2022
See cosmos/cosmos-sdk#8396 (comment)

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:automerge Automatically merge PR once all prerequisites pass.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants