Skip to content

[loongarch*-linux] -Crelocation-model=static should not access external data directly #118053

Closed
#119162
Closed
[loongarch*-linux] -Crelocation-model=static should not access external data directly#118053
#119162
Labels
C-bugCategory: This is a bug.O-loongarchTarget: LoongArch (LA32R, LA32S, LA64)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Description

@heiher
heiher
opened on Nov 19, 2023

I tried this code:

use std::ffi::CStr;
use std::os::raw::c_char;

extern "C" {
    static environ: *const *const c_char;
}

fn main() {
    unsafe {
        let mut env_ptr = environ;

        while !(*env_ptr).is_null() {
            let c_str_ptr = *env_ptr;
            let rust_str = CStr::from_ptr(c_str_ptr);

            println!("{:?}", rust_str.to_string_lossy());
            env_ptr = env_ptr.offset(1);
        }
    }
}

I expected to see the environments variables printed.

Instead, this happened: Aborted (core dumped)

Meta

rustc --version --verbose:

rustc 1.74.0 (79e9716c9 2023-11-13)
binary: rustc
commit-hash: 79e9716c980570bfd1f666e3b16ac583f0168962
commit-date: 2023-11-13
host: loongarch64-unknown-linux-gnu
release: 1.74.0
LLVM version: 17.0.4
Backtrace 

thread 'main' panicked at t.rs:12:16:
misaligned pointer dereference: address must be a multiple of 0x8 but is 0x28ee81ef1c000aef
stack backtrace:
   0: rust_begin_unwind
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:597:5
   1: core::panicking::panic_nounwind_fmt
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:106:14
   2: core::panicking::panic_misaligned_pointer_dereference
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:193:5
   3: t::main
             at ./t.rs:12:16
   4: core::ops::function::FnOnce::call_once
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread caused non-unwinding panic. aborting.
Aborted (core dumped)

Activity

  1. Imageheiher
    added
    C-bugCategory: This is a bug.
    on Nov 19, 2023
  2. Imagerustbot
    added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Nov 19, 2023

  3. heiher commented on Nov 19, 2023

    @heiher
    heiher
    on Nov 19, 2023
    ContributorAuthor

    @rustbot label O-loongarch

  4. Imagerustbot
    added
    O-loongarchTarget: LoongArch (LA32R, LA32S, LA64)
    on Nov 19, 2023

  5. heiher commented on Nov 19, 2023

    @heiher
    heiher
    on Nov 19, 2023
    ContributorAuthor

    This is the same issue as llvm/llvm-project#71645. For the linux kernel, we need to access external data directly when the relocation model is static to avoid GOT. It would better to add the -Cdirect-access-external-data argument to tune this behavior like clang.

  6. xry111 commented on Nov 20, 2023

    @xry111
    xry111
    on Nov 20, 2023
    Contributor

    From https://doc.rust-lang.org/rustc/codegen-options/index.html:

    static - non-relocatable code, machine instructions may use absolute addressing modes.

    So in the kernel it just should not be used for arch/loongarch: at least when CONFIG_RELOCATABLE=y we expect vmlinux to be a PIE, so non-relocatable code should not be allowed.

    arch/um already has:

    KBUILD_RUSTFLAGS += -Crelocation-model=pie

    Can we have the same?

  7. xry111 commented on Nov 20, 2023

    @xry111
    xry111
    on Nov 20, 2023
    Contributor

    From https://doc.rust-lang.org/rustc/codegen-options/index.html:

    static - non-relocatable code, machine instructions may use absolute addressing modes.

    So in the kernel it just should not be used for arch/loongarch: at least when CONFIG_RELOCATABLE=y we expect vmlinux to be a PIE, so non-relocatable code should not be allowed.

    arch/um already has:

    KBUILD_RUSTFLAGS += -Crelocation-model=pie

    Can we have the same?

    Oops, it will create GOT in vmlinux because we don't have -Cdirect-access-external-data. I think we should add -Cdirect-access-external-data, or make a new relocation model static-pie which is suitable for static PIEs like vmlinux.

  8. xry111 commented on Nov 20, 2023

    @xry111
    xry111
    on Nov 20, 2023
    Contributor

    arch/um already has:

    KBUILD_RUSTFLAGS += -Crelocation-model=pie

    Can we have the same?

    Oops, it will create GOT in vmlinux because we don't have -Cdirect-access-external-data. I think we should add -Cdirect-access-external-data, or make a new relocation model static-pie which is suitable for static PIEs like vmlinux.

    Another issue is we don't have a differentiate between KBUILD_RUSTFLAGS_MODULE and KBUILD_RUSTFLAGS_KERNEL yet. With either -Cdirect-access-external-data or -Crelocation-model=static-pie we still need such a differentiate.

  9. heiher commented on Nov 20, 2023

    @heiher
    heiher
    on Nov 20, 2023
    ContributorAuthor

    arch/um already has:

    KBUILD_RUSTFLAGS += -Crelocation-model=pie

    Can we have the same?

    Oops, it will create GOT in vmlinux because we don't have -Cdirect-access-external-data. I think we should add -Cdirect-access-external-data, or make a new relocation model static-pie which is suitable for static PIEs like vmlinux.

    Another issue is we don't have a differentiate between KBUILD_RUSTFLAGS_MODULE and KBUILD_RUSTFLAGS_KERNEL yet. With either -Cdirect-access-external-data or -Crelocation-model=static-pie we still need such a differentiate.

    https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Makefile?h=next-20231120#n568
    https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Makefile?h=next-20231120#n571

  10. heiher commented on Nov 20, 2023

    @heiher
    heiher
    on Nov 20, 2023
    ContributorAuthor

    From https://doc.rust-lang.org/rustc/codegen-options/index.html:

    static - non-relocatable code, machine instructions may use absolute addressing modes.

    So in the kernel it just should not be used for arch/loongarch: at least when CONFIG_RELOCATABLE=y we expect vmlinux to be a PIE, so non-relocatable code should not be allowed.

    arch/um already has:

    KBUILD_RUSTFLAGS += -Crelocation-model=pie

    Can we have the same?

    Updated: heiher/linux@a590c2f#diff-0e1f2cb4db0de17a95f13ee71d503167892fb028b00507977fcf9568066b33ecR88

  11. heiher commented on Nov 20, 2023

    @heiher
    heiher
    on Nov 20, 2023
    ContributorAuthor

    From https://doc.rust-lang.org/rustc/codegen-options/index.html:

    static - non-relocatable code, machine instructions may use absolute addressing modes.

    So in the kernel it just should not be used for arch/loongarch: at least when CONFIG_RELOCATABLE=y we expect vmlinux to be a PIE, so non-relocatable code should not be allowed.
    arch/um already has:

    KBUILD_RUSTFLAGS += -Crelocation-model=pie

    Can we have the same?

    Oops, it will create GOT in vmlinux because we don't have -Cdirect-access-external-data. I think we should add -Cdirect-access-external-data, or make a new relocation model static-pie which is suitable for static PIEs like vmlinux.

    In clang, -fdirect-access-external-data only works with no-pic. Therefore, even when using -fdirect-access-external-data with -fPIE, there are still GOT entries. I just noticed that is different from GCC.

    Update: Function doesn't support direct access in PIE mode.

    llvm/llvm-project@e2e82c9#diff-e724febedab9c1a2832bf2056d208ff02ddcb2e6f90b5a653afc9b19ac78a5d7L991-L995

  12. Imagesaethlin
    added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    and removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Nov 28, 2023
  13. Imagematthiaskrgr
    added a commit that references this issue on Feb 7, 2024

    Rollup merge of rust-lang#119162 - heiher:direct-access-external-data…

    4e54eea
  14. ImageNadrieril
    added 2 commits that reference this issue on Feb 7, 2024

    Rollup merge of rust-lang#119162 - heiher:direct-access-external-data…

    2e7e637

    Rollup merge of rust-lang#119162 - heiher:direct-access-external-data…

    7954c28
  15. Imagebors
    closed this as completedin 7954c28on Feb 7, 2024
  16. Imagerust-timer
    added a commit that references this issue on Feb 7, 2024

    Unrolled build for rust-lang#119162

    2242107
  17. Imageheiher
    added 2 commits that reference this issue on Oct 12, 2024

    Setting up indirect access to external data for loongarch64-linux-{mu…

    11bfb78

    Setting up indirect access to external data for loongarch64-linux-{mu…

    b1579e8
  18. Imagematthiaskrgr
    added a commit that references this issue on Oct 17, 2024

    Rollup merge of rust-lang#131583 - heiher:loong-issue-118053, r=jieyouxu

    9aee5d9
  19. Imagerust-timer
    added a commit that references this issue on Oct 17, 2024

    Unrolled build for rust-lang#131583

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.O-loongarchTarget: LoongArch (LA32R, LA32S, LA64)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions