Skip to content

Conversation

@sedited
Copy link
Contributor

@sedited sedited commented Dec 5, 2024

This adds a CI job for building the static consensus library and linking it to an executable. It uses newlib-cygwin as a C library for the final linking step. This ensure compatibility with this target going forward and can serve as a starting point for enabling bare metal builds for the entire kernel library. This would have also caught the error fixed in #31365.

@DrahtBot
Copy link
Contributor

DrahtBot commented Dec 5, 2024

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31425.

Reviews

See the guideline for information on the review process.

Type Reviewers
Concept ACK laanwj, hebasto

If your review is incorrectly listed, please copy-paste <!--meta-tag:bot-skip--> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #33974 (cmake: Check dependencies after build option interaction by hebasto)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@sedited sedited force-pushed the bare_metal_support branch from e75c002 to ece9dcd Compare December 5, 2024 09:12
@DrahtBot
Copy link
Contributor

DrahtBot commented Dec 5, 2024

🚧 At least one of the CI tasks failed.
Debug: https://github.com/bitcoin/bitcoin/runs/33960779294

Hints

Try to run the tests locally, according to the documentation. However, a CI failure may still
happen due to a number of reasons, for example:

  • Possibly due to a silent merge conflict (the changes in this pull request being
    incompatible with the current code in the target branch). If so, make sure to rebase on the latest
    commit of the target branch.

  • A sanitizer issue, which can only be found by compiling with the sanitizer and running the
    affected test.

  • An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

@maflcko
Copy link
Member

maflcko commented Dec 5, 2024

can serve as a starting point for enabling bare metal builds for the entire kernel library.

Interesting. Do you think this is possible at all, given that the kernel library links leveldb, which I'd presume is not bare-metal ready?

So I guess this mostly serves as a check that users can ship their own-brewed libbitcoinconsensus (or so, or subset of it)?

@sedited sedited force-pushed the bare_metal_support branch from ece9dcd to bc5adc3 Compare December 5, 2024 09:22
@sedited
Copy link
Contributor Author

sedited commented Dec 5, 2024

Interesting. Do you think this is possible at all, given that the kernel library links leveldb, which I'd presume is not bare-metal ready?

Yes, definitely not ready. I think the main hurdle is the background compaction, which I am not sure how to tackle. Maybe we'll find a solution for it eventually though, either by patching it, or allowing the user to bring their own utxos.

So I guess this mostly serves as a check that users can ship their own-brewed libbitcoinconsensus (or so, or subset of it)?

Yes, that is the goal for now.

@sedited sedited marked this pull request as ready for review December 5, 2024 10:05
@sedited sedited force-pushed the bare_metal_support branch from bc5adc3 to 4910ae5 Compare December 5, 2024 10:33
src/secp256k1/lib/libsecp256k1.a \
/opt/riscv-ilp32/riscv32-unknown-elf/lib/libstdc++.a \
/riscv/newlib/build/riscv32-unknown-elf/newlib/libc.a \
/riscv/newlib/build/riscv32-unknown-elf/newlib/libm.a \
Copy link
Member

Choose a reason for hiding this comment

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

Any specific reason to use the intermediate build and not the installed libraries from /opt/newlib, here?

cd /riscv/newlib
mkdir build && cd build
../configure \
--target=riscv32-unknown-elf --disable-newlib-io-float --enable-newlib-io-long-long --enable-newlib-io-long-double --with-arch=rv32gc --with-abi=ilp32 --disable-shared --disable-multilib\
Copy link
Member

Choose a reason for hiding this comment

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

Are you sure enabling i/o for long-double is needed? i don't believe we use this type anywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, all these flags were a mess. I was experimenting with linking in a range of other functionality, as well as running it on linux directly, and didn't prune stuff out nicely. Removed most of them again.

@laanwj
Copy link
Member

laanwj commented Dec 5, 2024

It uses newlib-cygwin as a C library for the final linking step.

Mentioning this because i had to look it up to be sure: newlib-cygwin has nothing to do with Windows whatsoever. It's simply a minimalist libc.

I think the main hurdle is the background compaction, which I am not sure how to tackle.

Could be a periodic foreground task, if threads aren't available? But yes, this would imply patching leveldb, there is no such API right now.


if [[ ${BARE_METAL_RISCV} == "true" ]]; then
${CI_RETRY_EXE} git clone --depth=1 https://github.com/riscv-collab/riscv-gnu-toolchain -b 2024.11.22 /riscv/gcc
cd /riscv/gcc
Copy link
Member

Choose a reason for hiding this comment

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

style-wise, it would be good to not use cd in the CI scripts, because it affects the global state for all remaining lines.

It is better to wrap it into (), for example ( cd a ; foo(); ) (or similar).

CFLAGS_FOR_TARGET="-march=rv32gc -mabi=ilp32 -mcmodel=medlow "\
CXXFLAGS_FOR_TARGET="-std=c++20 -march=rv32gc -mabi=ilp32 -mcmodel=medlow"
make -j "$MAKEJOBS"
make install
Copy link
Member

Choose a reason for hiding this comment

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

It would be good to rm -rf everything duplicate. Otherwise, you are using up space twice:

$ podman image ls | grep riscv
localhost/ci_native_riscv_bare  latest      dfa9b8223b62  5 minutes ago  13.9 GB

See the llvm build on how to do this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should be better now:

docker image ls | grep riscv
ci_native_riscv_bare   latest    55627eefe6d7   3 minutes ago   2.8GB

@sedited
Copy link
Contributor Author

sedited commented Dec 6, 2024

Updated 4910ae5 -> f277600 (bare_metal_support_0 -> bare_metal_support_1, compare)

  • Addressed @maflcko's comment, removing sources after install step.
  • Addressed @maflcko's comment, wrapped cd step into a subshell
  • Addressed @laanwj's comment, use the installed lib
  • Addressed @laanwj's comment, removing a bunch of unneeded/superfluous flags
  • Added a start section to the binary for the global pointer and returning an exit code. Though not needed, since we are only checking that it links, I feel like this makes the example a bit clearer.

call main
# Put Exit2 system call number into the a7 register
Copy link
Member

@laanwj laanwj Dec 10, 2024

Choose a reason for hiding this comment

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

concept ACK on making it actually runnable somewhat
i was confused for a moment here, as to what syscall numbers mean for bare-metal
maybe add "Linux" to the comment

@laanwj
Copy link
Member

laanwj commented Dec 10, 2024

Concept ACK, this looks like the minimum required to sanity check that libconsensus.a can be compiled for, and linked for bare-metal RISC-V.
It is not enough to test that it actually works (this would require a lot more, quite nasty low-level code), but maybe that's out of scope for this project. At the least it is for this PR.

@hebasto
Copy link
Member

hebasto commented Dec 14, 2024

Concept ACK.

)
endif()

if(NOT CMAKE_SYSTEM_NAME STREQUAL "Generic")
Copy link
Member

Choose a reason for hiding this comment

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

I imagine that expanding this build scenario might enable building boost and libevent in depends, no?

If so, the Boost check should have another option to be disabled.

Additionally, mind considering this comment:

TODO: Not all targets, which will be added in the future, require
Boost. Therefore, a proper check will be appropriate here.

which, in turn, was based on this legacy code:

bitcoin/configure.ac

Lines 1247 to 1251 in 32efe85

if test "$build_bitcoin_wallet$build_bitcoin_cli$build_bitcoin_tx$build_bitcoin_util$build_bitcoind$bitcoin_enable_qt$use_tests$use_bench$enable_fuzz_binary" = "nonononononononono"; then
use_boost=no
else
use_boost=yes
fi

@DrahtBot
Copy link
Contributor

DrahtBot commented Apr 4, 2025

CI failure:

[12:50:33.743] gmake: *** No rule to make target 'install'.  Stop.

@sedited
Copy link
Contributor Author

sedited commented Aug 7, 2025

Rebased f277600 -> ec7c86c (bare_metal_support_1 -> bare_metal_support_2, compare)

  • Fixed a bunch of silent and proper merge conflicts.

@sedited
Copy link
Contributor Author

sedited commented Sep 4, 2025

@sedited
Copy link
Contributor Author

sedited commented Sep 17, 2025

Rebased a577bbe -> e254de7 (bare_metal_support_3 -> bare_metal_support_4, compare)

A bare metal build is now supported by setting CMAKE_SYSTEM_NAME=Generic

Skip the platform-dependent feature checks, such as threads and atomics,
which are typically not available on bare metal. Also only make the
boost headers mandatory if they exist for the target.
@sedited
Copy link
Contributor Author

sedited commented Dec 23, 2025

Rebased e254de7 -> dc53679 (bare_metal_support_4 -> bare_metal_support_5, compare)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Platform Protability

Development

Successfully merging this pull request may close these issues.

6 participants