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.

Sign up for GitHub

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

Jump to bottom

Pass rustc the equivalent of -Wframe-larger-than=1000 #121

Open
ojeda opened this issue Mar 18, 2021 · 10 comments
Open

Pass rustc the equivalent of -Wframe-larger-than=1000 #121

ojeda opened this issue Mar 18, 2021 · 10 comments
Labels
• toolchain Related to `rustc`, `bindgen`, `rustdoc`, LLVM, Clippy...

Comments

@ojeda
Copy link
Member

ojeda commented Mar 18, 2021

No description provided.

@ojeda ojeda added • toolchain Related to `rustc`, `bindgen`, `rustdoc`, LLVM, Clippy... prio: normal labels Mar 18, 2021
@ojeda ojeda mentioned this issue Mar 18, 2021
Merged
@ojeda ojeda changed the title Pass rustc the equivalent of -Wframe-larger-than=1000 Pass rustc the equivalent of -Wframe-larger-than=1000 Mar 18, 2021
@mpe
Copy link

mpe commented Apr 10, 2021

Is there such a thing? I had a look and couldn't find it, but I'm not a rustc expert.

@ojeda
Copy link
Member Author

ojeda commented Apr 10, 2021

Not sure -- we may need to implement it ourselves! :)

@bjorn3
Copy link
Member

bjorn3 commented Apr 15, 2021 •
edited
Loading

No, there isn't a direct option, but there are things that can help. There is rust-lang/rust#83519 for moves of large values. This includes assignments. For stack frame sizes, only LLVM knows about it. With -Z emit-stack-sizes it is possible to tell LLVM to add a section containing info about stack frame sizes. This option was added to rustc for https://github.com/japaric/cargo-call-stack.

@mpe
Copy link

mpe commented Apr 16, 2021

OK. I used -Z emit-stack-sizes to debug issue #155, which worked well enough to find the large functions. I guess that's not useful for an upstream stack size warning option though, because it would require nightly rustc (AIUI).

@TheSven73
Copy link
Collaborator

@mpe would you mind sharing how you obtained a list of function stack sizes using -Z emit-stack-sizes? I'd like to do the same for arm 32-bit. It's quite possible that stack overflows are happening there too.

@mpe
Copy link

mpe commented Apr 16, 2021

Something like this:

$ make KRUSTCFLAGS="-Z emit-stack-sizes"
$ cargo install stack-sizes
$ stack-sizes vmlinux | sort -nk 2

@TheSven73 TheSven73 mentioned this issue Apr 16, 2021
Merged
@ojeda
Copy link
Member Author

ojeda commented Apr 16, 2021 •
edited
Loading

I guess that's not useful for an upstream stack size warning option though, because it would require nightly rustc (AIUI).

Yeah -- we should use it nevertheless. That way the rustc folks know it is useful and being used (see the #2 list), and that we will want it stabilized at some point. If really needed, we can always gate it or take it out later.

@bjorn3
Copy link
Member

bjorn3 commented Apr 16, 2021

I don't know what stability guarantee LLVM has for this feature. If LLVM doesn't guarantee that it will remain the same forever, I think it is unlikely that it will be stabilized in rustc.

@ojeda
Copy link
Member Author

ojeda commented Apr 16, 2021

My thinking was that given Clang supports -Wframe-larger-than=, LLVM will need to support the feature one way or another, which means it should be fairly easy for rustc to keep providing it too.

@bjorn3
Copy link
Member

bjorn3 commented Apr 16, 2021

Clang doesn't use the stack size section. Instead it instructs LLVM to emit a diagnostic whenever the stack size is above a certain threshold. Rustc doesn't have any support for handling LLVM diagnostics except for inline asm.

https://github.com/llvm/llvm-project/blob/a9968c0a339ab47f5d6da1c513b2754f1e98a596/llvm/lib/CodeGen/PrologEpilogInserter.cpp#L278-L284

llvm/llvm-project@728c554

ojeda pushed a commit that referenced this issue Jan 22, 2024
@chenhengqi @chenhuacai
LoongArch: BPF: Support 64-bit pointers to kfuncs
21c5ae5 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  #119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  #120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  #121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  #122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  #123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  #124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  #125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  #126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  #127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  #128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  #129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  #130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  #486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
• toolchain Related to `rustc`, `bindgen`, `rustdoc`, LLVM, Clippy...
Milestone
No milestone
Development

No branches or pull requests
4 participants
@mpe @TheSven73 @ojeda @bjorn3