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

Project name cannot be "uprobe" for uprobe programs #1027

Open
gemesa opened this issue Sep 11, 2024 · 1 comment
Open

Project name cannot be "uprobe" for uprobe programs #1027

gemesa opened this issue Sep 11, 2024 · 1 comment

Comments

@gemesa
Copy link

gemesa commented Sep 11, 2024

It seems that the chosen project name cannot be "uprobe" (at least when selecting uprobe as the program type) because the following error occurs. It is not a serious issue but I think it is worth mentioning.

$ cargo generate https://github.com/aya-rs/aya-template
⚠️   Favorite `https://github.com/aya-rs/aya-template` not found in config, using it as a git repository: https://github.com/aya-rs/aya-template
🤷   Project Name: uprobe
🔧   Destination: /home/gemesa/tmp/uprobe ...
🔧   project-name: uprobe ...
🔧   Generating template ...
✔ 🤷   Which type of eBPF program? · uprobe
🤷   Target to attach the (u|uret)probe? (e.g libc): libc
🤷   Function name to attach the (u|uret)probe? (e.g getaddrinfo): uname
🔧   Moving generated files into: `/home/gemesa/tmp/uprobe`...
🔧   Initializing a fresh Git repository
✨   Done! New project created /home/gemesa/tmp/uprobe
$ cd uprobe
$ cargo xtask build-ebpf
...
Compiling uprobe-common v0.1.0 (/home/gemesa/tmp/uprobe/uprobe-common)
   Compiling aya-log-ebpf v0.1.0
   Compiling uprobe-ebpf v0.1.0 (/home/gemesa/tmp/uprobe/uprobe-ebpf)
error: linking with `bpf-linker` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/gemesa/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/gemesa/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/gemesa/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/gemesa/.cargo/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/gemesa/.local/bin" VSLANG="1033" "bpf-linker" "--export-symbols" "/tmp/rustcDLgpCO/symbols" "/tmp/rustcDLgpCO/symbols.o" "/home/gemesa/tmp/uprobe/uprobe-ebpf/../target/bpfel-unknown-none/debug/deps/uprobe-ef76186f7697bee3.uprobe.b1b08c5f5056932e-cgu.0.rcgu.o" "--cpu" "generic" "-o" "/home/gemesa/tmp/uprobe/uprobe-ebpf/../target/bpfel-unknown-none/debug/deps/uprobe-ef76186f7697bee3" "-O3" "--debug"
  = note: unable to open LLVM shared lib /home/gemesa/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-19-rust-1.83.0-nightly.so: /home/gemesa/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-19-rust-1.83.0-nightly.so: file too short
          ERROR llvm: <unknown>:0: uprobe changed binding to STB_GLOBAL
          
          ERROR llvm: <unknown>:0: symbol 'uprobe' is already defined
          
          Error: LLVM issued diagnostic with error severity
          

error: could not compile `uprobe-ebpf` (bin "uprobe") due to 1 previous error
thread 'main' panicked at xtask/src/build_ebpf.rs:65:5:
assertion failed: status.success()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
@tyrone-wu
Copy link
Contributor

I believe this is actually a bug from aya-template.

The error comes from the template generating #[uprobe] with no arguments, which results in the error (the error itself is correct in that the ELF section name is reserved).

The template should have generated the proc macro to be #[uprobe(path="<attach>", function="<function>")], which produces a section name of uprobe/<path>:<function>, which shouldn't result in a collision with uprobe function name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants