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

statics are null on x86_64-unknown-linux-none #134763

Closed
m-mueller678 opened this issue Dec 25, 2024 · 4 comments
Closed

statics are null on x86_64-unknown-linux-none #134763

m-mueller678 opened this issue Dec 25, 2024 · 4 comments
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. O-linux-none Operating system: Linux, with the libcless linux-none target T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@m-mueller678
Copy link

m-mueller678 commented Dec 25, 2024

when compiling for x86_64-unknown-linux-none, the static items in the following code snippet have null pointers as address. The inline versions work as expected. The exit code of the program is 10.

#![no_std]
#![no_main]

use syscalls::Sysno;

static SLICE: &[u8; 5] = b"hello";
static STRING:&str = "hello";

#[no_mangle]
pub extern "C" fn _start() -> ! {
    let static_slice = SLICE.as_ptr().is_null()  as usize;
    let inline_slice = b"hello".as_ptr().is_null() as usize;
    let static_str = STRING.as_ptr().is_null() as usize;
    let inline_str = "hello".as_ptr().is_null() as usize;
    let exit_code = static_slice<<3|inline_slice<<2|static_str<<1|inline_str;
    unsafe {
        syscalls::syscall1(Sysno::exit,exit_code).unwrap();
    }
    loop{}
}


#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
    loop{}
}

Meta

rustc --version --verbose:

rustc 1.85.0-nightly (409998c4e 2024-12-24)
binary: rustc
commit-hash: 409998c4e8cae45344fd434b358b697cc93870d0
commit-date: 2024-12-24
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.6

cargo config:

[build]
target = "x86_64-unknown-linux-none"

[unstable]
build-std = ["core"]
@m-mueller678 m-mueller678 added the C-bug Category: This is a bug. label Dec 25, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Dec 25, 2024
@Noratrieb
Copy link
Member

Noratrieb commented Dec 25, 2024

Your code sample does not compile, it has a syntax error and depends on a crate that you didn't specify in the cargo.toml. After adding the semicolon and removing the syscall (and also specifying panic=abort explicitly because this is incorrectly a panic=unwind target, fixed in #134765) I got a program.
The ELF is of type DYN, making it a position-independent executable. There are two relocations, probably for the statics.
With the default configuration, you're gonna have to implement a dynamic loader yourself to resolve these relocations. You can use the -Crelocation-model=static rustc flag to change this.
With that, the relocations are gone, it's no longer a PIE, and you should be able to run it without implementing a dynamic loader.
Maybe that should be the default for the target.

@Noratrieb Noratrieb added O-linux-none Operating system: Linux, with the libcless linux-none target T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Dec 25, 2024
@Noratrieb
Copy link
Member

Opened #134765 to change the defaults to more appropriate ones that should make your program work.

@jieyouxu
Copy link
Member

UPD: #134765 opts to instead documents PIE as default target behavior and mentions using -Crelocation-model=static if position-dependent is desired instead.

@jieyouxu jieyouxu added C-discussion Category: Discussion or questions that doesn't represent real issues. and removed C-bug Category: This is a bug. labels Dec 29, 2024
jieyouxu added a commit to jieyouxu/rust that referenced this issue Dec 29, 2024
…illy, r=jieyouxu

Improve default target options for x86_64-unknown-linux-none

Without a standard library, we cannot unwind, so it should be panic=abort by default.

Additionally, it does not have std because while it is Linux, it cannot use libc, which std uses today for Linux.

Using PIE by default may be surprising to users, as shown in rust-lang#134763, so I've documented it explicitly. I'm not sure if we want to count that as fixing the issue or not.

cc `@morr0ne,` as you added the target (and are the maintainer), and `@Noratrieb,` who reviewed that PR (:D).
bors added a commit to rust-lang-ci/rust that referenced this issue Dec 29, 2024
…ly, r=jieyouxu

Improve default target options for x86_64-unknown-linux-none

Without a standard library, we cannot unwind, so it should be panic=abort by default.

Additionally, it does not have std because while it is Linux, it cannot use libc, which std uses today for Linux.

Using PIE by default may be surprising to users, as shown in rust-lang#134763, so I've documented it explicitly. I'm not sure if we want to count that as fixing the issue or not.

cc `@morr0ne,` as you added the target (and are the maintainer), and `@Noratrieb,` who reviewed that PR (:D).
@Noratrieb
Copy link
Member

I'm closing this, since the problem should be fixed with the relocation model. The docs now mention this, but the default is still PIC, so people might run into this again, but there's not that much we can do about it.
If relocation model static doesn't fix your issue please comment again or open a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. O-linux-none Operating system: Linux, with the libcless linux-none target T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants