Skip to content

Test linking and running no_std binaries #138904

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

Merged
merged 1 commit into from
Apr 11, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions tests/ui/no_std/simple-runs.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
//! Check that `no_std` binaries can link and run without depending on `libstd`.

//@ run-pass
//@ compile-flags: -Cpanic=abort
//@ ignore-wasm different `main` convention
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unsure if we need to add more to the ignores here? Is something like ignore-embedded a thing, and would it make sense?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm guessing run-pass already omits platforms that can't run standalone executables, cc @jieyouxu for a better answer.

Copy link
Member

@jieyouxu jieyouxu Apr 4, 2025

Choose a reason for hiding this comment

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

See

let proc_res = match &*self.config.target {
, I believe in the general case run-pass intentionally does not try to be "smart" and omit platforms that can't run standalone executables. Generally tests will need //@ ignore-cross-compile if they need to run the test binary (but that only runs on host).


#![no_std]
#![no_main]

use core::ffi::{c_char, c_int};
use core::panic::PanicInfo;

// # Linux
//
// Linking `libc` is required by crt1.o, otherwise the linker fails with:
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 fun to have a _start lib-less linux binary as well

// > /usr/bin/ld: in function `_start': undefined reference to `__libc_start_main'
//
// # Apple
//
// Linking `libSystem` is required, otherwise the linker fails with:
// > ld: dynamic executables or dylibs must link with libSystem.dylib
//
// With the new linker introduced in Xcode 15, the error is instead:
// > Undefined symbols: "dyld_stub_binder", referenced from: <initial-undefines>
//
// This _can_ be worked around by raising the deployment target with
// MACOSX_DEPLOYMENT_TARGET=13.0, though it's a bit hard to test that while
// still allowing the test suite to support running with older Xcode versions.
#[cfg_attr(all(not(target_vendor = "apple"), unix), link(name = "c"))]
#[cfg_attr(target_vendor = "apple", link(name = "System"))]
extern "C" {}

#[panic_handler]
fn panic_handler(_info: &PanicInfo<'_>) -> ! {
loop {}
}

#[no_mangle]
extern "C" fn main(_argc: c_int, _argv: *const *const c_char) -> c_int {
0
}
Loading