aya-rs / bpf-linker Goto Github PK

View Code? Open in Web Editor NEW

182.0 182.0 41.0 674 KB

Simple BPF static linker

License: Apache License 2.0

Rust 99.84% C 0.16%

bpf-linker's People

Contributors

Stargazers

Watchers

bpf-linker's Issues

workflows: ensure bpf-linker works for aya integration tests

It'd be nice to know that changes to bpf-linker don't break the aya integration tests.

Locally I find that a recent build of #35 fails to link on many of the tests.

Add --btf option

Before we merge the fix-di branch into main, we should add a --btf cmdline option. Then we should keep stripping debug info in main by default unless --btf is passed. This way we give folks an opt-in way to test BTF emission (compile with -C link-arg=--btf), without impacting people who don't need BTF.

BTF type name is too long

On some kernels, BTF aware programs fails to load because BTF type name is too long.
Before kernel 6.1 maximum name length is 128 bytes, which might quickly get overflown when dealing with Rust namespaces.
After kernel 6.1 the maximum length is 512 bytes, which is less prone to overflow.

Anyway, there is a strong need to control the maximum length returned by sanitize_type_name function to maximize program compatibility.

Example:
[220] STRUCT LruHashMap_3C_u128_2C__20_kunai_common_3A__3A_events_3A__3A_Event_3C_kunai_common_3A__3A_events_3A__3A_execve_3A__3A_ExecveData_3E__3E_ size=28 vlen=3 Invalid name

Support dynamic linking with `llvm-sys`

Under Alpine Linux, i.e. a target for which static linking is the default, installing bpf-linker (without the default features as per the docs), fails unless, for one, rustc option -C target-feature=-crt-static is set. This because bpf-linker's build uses procedural macros which are incompatible with static linking currently. However, bpf-linkers dependency llvm-sys has a build script which results in static linking by default:

https://gitlab.com/taricorp/llvm-sys.rs/-/blob/main/README.md?ref_type=heads#cargo-features

If none are enabled, force-static is assumed (matching the behavior of older version of llvm-sys that did not support dynamic linking).

Solution

Please respond to this issue with your analysis of the problem and alternatives/work-arounds. If we agree, I'm ready to submit a PR.

Either support configuring one or more llvm-sym linkage modes as a Cargo feature for bpf-linker, or perhaps set prefer-dynamic or even force-dynamic by default, or both.

Note from the previously cited docs:

Most crates that depend on llvm-sys should not automatically enable any of these features, because the appropriateness of any given option usually depends on the configuration of the system on which the library is being compiled.

For example, add this to your Cargo.toml.

Cargo.toml

[features]
llvm-sys-force-dynamic = ["llvm-sys/force-dynamic"]

LLVM17 cold callsite categorization breaks inlining

This is a wrap up of what has been discussed in: https://discord.com/channels/855676609003651072/1026937450624450652/1155989596870549584

After migration to LLVM17, LLVM has the functionality to track cold and hot callsite.
This categorization, based on call frequency, impacts the inlining strategy in the following way:

cold sites will less likely be inlined
cold site status superseed inlinehint LLVM attribute set by #[inline] tag in Rust
hot call sites will be more likely to get inlined

While the strategy concerning hot callsite does not seem to be an issue, the one concerning cold ones seems problematic.
Even though, #[inline(always)] never guarantee that the function will get inlined, it seems to happen rather frequently that always_inline functions also categorized as cold callsite do not get inlined at all. This creates loads of errors in bpf-linker preventing the linking from happening. All the errors observed being due to too large return values (i.e. > 64 bits in size).

Why this change is needed: there must be a way to programmatically ensure that functions that return results larger than 64 bits get inlined https://discord.com/channels/855676609003651072/1026937450624450652/1155834661558288424

The best solution to opt for and have an inlining strategy close to what bpf-linker had with LLVM16 is to disable cold callsite categorization. This is possible by passing --llvm-args=--cold-callsite-rel-freq=0 to bpf-linker.

Error while installing on target aarch64-unknown-linux-gnu

I am doing cargo install bpf-linker --no-default-features in docker container and below is the error

29.52 error: linking with `cc` failed: exit status: 1
29.52   |
29.52   = note: LC_ALL="C" PATH="/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/bin:/usr/local/cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "cc" "/tmp/rustcPzbciC/symbols.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.00.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.01.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.02.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.03.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.04.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.05.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.06.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.07.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.08.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.09.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.10.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.11.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.12.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.13.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.14.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.bpf_linker.fdd99572382040e0-cgu.15.rcgu.o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15.27m78z4pd158cm06.rcgu.o" "-Wl,--as-needed" "-L" "/tmp/cargo-installXTb0II/release/deps" "-L" "/tmp/cargo-installXTb0II/release/build/llvm-sys-18e2462374bd791d/out" "-L" "/usr/lib/llvm-16/lib" "-L" "/usr/lib/aarch64-linux-gnu" "-L" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/tmp/cargo-installXTb0II/release/deps/libbpf_linker-8e1ce6bb82828f5b.rlib" "/tmp/cargo-installXTb0II/release/deps/libllvm_sys-2172ef8ffbe97be5.rlib" "/tmp/cargo-installXTb0II/release/deps/libar-6c5c1a48f3f88aa8.rlib" "/tmp/cargo-installXTb0II/release/deps/libthiserror-07965433dd303574.rlib" "/tmp/cargo-installXTb0II/release/deps/libsimplelog-2674f6b05aadb9ab.rlib" "/tmp/cargo-installXTb0II/release/deps/libtime-70953665eed6ced7.rlib" "/tmp/cargo-installXTb0II/release/deps/libnum_threads-f0a438b56caa9782.rlib" "/tmp/cargo-installXTb0II/release/deps/liblibc-dcda8b766e21ab4d.rlib" "/tmp/cargo-installXTb0II/release/deps/libitoa-02906aed80681e09.rlib" "/tmp/cargo-installXTb0II/release/deps/libtime_core-8d3f12e32649c10d.rlib" "/tmp/cargo-installXTb0II/release/deps/libderanged-a7879ee55da207df.rlib" "/tmp/cargo-installXTb0II/release/deps/libpowerfmt-afe63e2eb99bfb69.rlib" "/tmp/cargo-installXTb0II/release/deps/libtermcolor-05554e663eaec22f.rlib" "/tmp/cargo-installXTb0II/release/deps/liblog-f79900b5d53162a1.rlib" "/tmp/cargo-installXTb0II/release/deps/libclap-f12af99fe9862f6a.rlib" "/tmp/cargo-installXTb0II/release/deps/libclap_builder-50fbcd5a064d5e35.rlib" "/tmp/cargo-installXTb0II/release/deps/libstrsim-e42a24a8ba2eb11e.rlib" "/tmp/cargo-installXTb0II/release/deps/libanstream-57e5f7075a77f135.rlib" "/tmp/cargo-installXTb0II/release/deps/libanstyle_query-8919ff40739dc5c2.rlib" "/tmp/cargo-installXTb0II/release/deps/libcolorchoice-f88867612aa9c85c.rlib" "/tmp/cargo-installXTb0II/release/deps/libanstyle_parse-dd712711e41df08e.rlib" "/tmp/cargo-installXTb0II/release/deps/libutf8parse-c12d3e069b745eda.rlib" "/tmp/cargo-installXTb0II/release/deps/libclap_lex-c502c5d3bb7631f4.rlib" "/tmp/cargo-installXTb0II/release/deps/libanstyle-7fa7292a05e8d386.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-b206f34cf97d155b.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libpanic_unwind-1d68e471430fd090.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libobject-92c87e63ac3ce1ad.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libmemchr-4afcffa641740b48.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libaddr2line-5bc3b505b20904cf.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgimli-60203c3628e394df.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_demangle-212440dcc15d3bfb.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd_detect-051e3f9413a4f8c9.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libhashbrown-23fcf4484edc3045.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-63578e0e651dbbec.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libminiz_oxide-5ecf91dc3a482e28.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libadler-ee5595b5945740e0.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libunwind-bd0f4f9153aced84.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcfg_if-38373957c233c99d.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-bd43750bd611b8bd.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/liballoc-c32a524477970171.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_core-d67d6fef36d10faf.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcore-0853063f4f3ed5e5.rlib" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcompiler_builtins-4f71645b43783df4.rlib" "-Wl,-Bdynamic" "-lrt" "-ldl" "-lpthread" "-lm" "-lz3" "-lz" "-lzstd" "-ltinfo" "-lxml2" "-lstdc++" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/usr/local/rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-o" "/tmp/cargo-installXTb0II/release/deps/bpf_linker-13d2630d934f9e15" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs"
29.52   = note: /usr/bin/ld: cannot find -lzstd
29.52           collect2: error: ld returned 1 exit status
29.52

My Docker File

FROM rust:bullseye as builder
RUN rustup update
RUN rustup default nightly

RUN apt-get update \
    && apt-get install -y software-properties-common \
    && wget https://apt.llvm.org/llvm-snapshot.gpg.key \
    && apt-key add llvm-snapshot.gpg.key \
    && rm -f llvm-snapshot.gpg.key \
    && add-apt-repository "deb http://apt.llvm.org/bullseye/ llvm-toolchain-bullseye-16 main" \
    && apt-get update \
    && apt-get install -y \
    libssl-dev \
    libpolly-16-dev \
    libclang-16-dev \
    llvm-16-dev \
    pkg-config
RUN apt update && apt install -y libbpf0
RUN rustup target add aarch64-unknown-linux-gnu
# RUN apt-get install -y clang-16 lldb-16 lld-16
RUN cargo install bpf-linker --no-default-features

Am I missing any more libraries ?

bpf-linker is not compatbile with `-fuse-ld`

I encountered this while trying to run aya-rs/aya#916 locally.

warning: [email protected]:   = note: ... "-fuse-ld=mold"
warning: [email protected]:   = note: error: unexpected argument '-f' found
warning: [email protected]:           
warning: [email protected]:             tip: to pass '-f' as a value, use '-- -f'
warning: [email protected]:           
warning: [email protected]:           Usage: bpf-linker [OPTIONS] --output <OUTPUT> [INPUTS]...
warning: [email protected]:           
warning: [email protected]:           For more information, try '--help'.

This is because I use the mold linker locally in my cargo.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = [
    "-C", "link-arg=-fuse-ld=mold",
]

Confusingly, I only have this set for when the target is x86_64. Is this another bug?

Find a way to annotate structs which are supposed to be anonymized

For now we do this, which is not acceptable:

bpf-linker/src/llvm/di.rs

Line 89 in 60ce107

if name.starts_with("HashMap<") {

We need to find a way of annotating a struct which will:

Use existing Rust functionality (we don't want changes in rustc, yet).
Annotate the DI node somehow.

Write a btfdump utility, stop using bpftool btf dump in btf tests

bpf-linker's BTF tests require bpftool to run the BTF tests, as they run bpftool btf dump. We should write our own btfdump utility that outputs the same format as bpftool btf dump.

Become a Tier 2 Rust Target

Seeing as BPF has spent a few release cycles at Tier 3, we should think about Tier 2.

This is the policy for Tier 2 targets: https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-2-target-policy

Tier 3 checklist was here

A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.)

✔️

A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.

The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance documentation of the target.

That would be @alessandrod and @dave-tucker and anyone else who would like to volunteer

The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target.

I think this is ok, since codegen is done in the linker. The only issue might be #1 since that will require the debug bitcode not to break LLVM's dwarf to btf conversion. Which may require LLVM and/or rustc patches.

The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target. If at all possible, this documentation should show how to run Rust programs and tests for the target using emulation, to allow anyone to do so. If the target cannot be feasibly emulated, the documentation should explain how to obtain and work with physical hardware, cloud systems, or equivalent.

The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

I'm unclear where this documentation should live, but I think it's do-able

Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.

The right approach to handling a missing feature from a target may depend on whether the target seems likely to develop the feature in the future. In some cases, a target may be co-developed along with Rust support, and Rust may gain new features on the target as that target gains the capabilities to support those features.

As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target's value will take this limitation into account.

This is going to require a lot of work 🤔 We'll need to create an issue to track exactly what we can and can't support here and make sure it gets folded in to the documentation above.

The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. (This requirement does not apply to arbitrary security enhancements or mitigations provided by code generation backends, only to those properties needed to ensure safe Rust code cannot cause undefined behavior or other unsoundness.) If this requirement does not hold, the target must clearly and prominently document any such limitations as part of the target's entry in the target tier list, and ideally also via a failing test in the testsuite. The Rust compiler team must be satisfied with the balance between these limitations and the difficulty of implementing the necessary features.

For example, if Rust relies on a specific code generation feature to ensure that safe code cannot overflow the stack, the code generation for the target should support that feature.

If the Rust compiler introduces new safety properties (such as via new capabilities of a compiler backend), the Rust compiler team will determine if they consider those new safety properties a best-effort improvement for specific targets, or a required property for all Rust targets. In the latter case, the compiler team may require the maintainers of existing targets to either implement and confirm support for the property or update the target tier list with documentation of the missing property.

This is also going to require some research, especially as integer overflow checks in the debug profile upset the eBPF verifier.

If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C". The C calling convention does not need to be the default Rust calling convention for the target, however.

Yup, I guess we'd need to implement that too.

The target must build reliably in CI, for all components that Rust's CI considers mandatory.

✔️

The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, ./x.py test --no-run, or equivalent "smoke tests". In particular, this requirement may apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems.
Building the target in CI must not take substantially longer than the current slowest target in CI, and should not substantially raise the maintenance burden of the CI infrastructure. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account.

Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 targets should not require using the target as the host for builds, even if the target supports host tools.

✔️

In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems. This is a subjective requirement, to be evaluated by the approving teams.

✔️

The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

✔️

Build is failing

I was just wondering why the build is failing and if there's any plan to fix it.
Seems like there has not been any successful build since ~2 months:

pick up the latest version of aya's rustc-llvm-proxy

This depends on making and publishing a new tag or release of https://github.com/aya-rs/rustc-llvm-proxy. Besides using the latest code of that repository, it would also make the bpf-linker to depend on and use the current (0.7.*) version of https://crates.io/crates/libloading - currently 0.7.4.

failure linking module `perf_event` template in bpf-linker

Following the README guide, you need to install bpf-linker on the aarch64 environment as follows.

Right, I've been tested aya-rs on my Apple M2 VMware Fusion Eenvironment with Fedora 40.

$ uname -a
Linux fedora 6.11.0-0.rc1.20240729gitdc1c8034e31b.16.fc41.aarch64+debug #1 SMP PREEMPT_DYNAMIC Tue Jul 30 05:03:16 KST 2024 aarch64 GNU/Linux

I have confirmed that this works well with the XDP template.

If your target is aarch64-unknown-linux-gnu (i.e. Linux on Apple Silicon) you will have to use the external LLVM method.

So, I build with external LLVM method option.

$ cargo install bpf-linker --no-default-features

But, there seems to be error: failure linking module /home/paran/perf-aya-rs/perf-aya-rs-ebpf/../target/bpfel-unknown-none/debug/deps/perf_aya_rs-58caae9717f08677.perf_aya_rs.4b0d608d0cf878c2-cgu.0.rcgu.o

This is my log when linking failed.

$ 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: perf-aya-rs
🔧   Destination: /home/paran/perf-aya-rs ...
🔧   project-name: perf-aya-rs ...
🔧   Generating template ...
✔ 🤷   Which type of eBPF program? · perf_event
🔧   Moving generated files into: `/home/paran/perf-aya-rs`...
🔧   Initializing a fresh Git repository
✨   Done! New project created /home/paran/perf-aya-rs

$ cd perf-aya-rs/
$ cargo xtask build-ebpf
   ...
   Compiling xtask v0.1.0 (/home/paran/perf-aya-rs/xtask)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 45.50s
     Running `target/debug/xtask build-ebpf`
   ...
   Compiling core v0.0.0 (/home/paran/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   ...
   Compiling rustc-std-workspace-core v1.99.0 (/home/paran/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   ...
   Compiling perf-aya-rs-common v0.1.0 (/home/paran/perf-aya-rs/perf-aya-rs-common)
   Compiling aya-log-ebpf v0.1.0
   Compiling perf-aya-rs-ebpf v0.1.0 (/home/paran/perf-aya-rs/perf-aya-rs-ebpf)
error: linking with `bpf-linker` failed: exit status: 2
  |
  = note: LC_ALL="C" PATH="/home/paran/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/bin:/home/paran/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/bin:/home/paran/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/bin:/home/paran/.cargo/bin:/home/paran/.local/bin:/home/paran/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/paran/bin:/home/paran/usr/bin:/home/paran/bin:/home/paran/usr/bin" VSLANG="1033" "bpf-linker" "--export-symbols" "/tmp/rustcW2rljA/symbols" "/tmp/rustcW2rljA/symbols.o" "/home/paran/perf-aya-rs/perf-aya-rs-ebpf/../target/bpfel-unknown-none/debug/deps/perf_aya_rs-58caae9717f08677.perf_aya_rs.4b0d608d0cf878c2-cgu.0.rcgu.o" "--cpu" "generic" "-o" "/home/paran/perf-aya-rs/perf-aya-rs-ebpf/../target/bpfel-unknown-none/debug/deps/perf_aya_rs-58caae9717f08677" "-O3" "--debug"
  = note: error: failure linking module /home/paran/perf-aya-rs/perf-aya-rs-ebpf/../target/bpfel-unknown-none/debug/deps/perf_aya_rs-58caae9717f08677.perf_aya_rs.4b0d608d0cf878c2-cgu.0.rcgu.o

error: could not compile `perf-aya-rs-ebpf` (bin "perf-aya-rs") 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

Do you know anyone who could help with this, or could you provide some hints for debugging it myself?

I think it would be great if I could looking into it and contribute to this issue.

emit btf debug info for loading with libbpf-rs

Use tracing crate for logging

We now use env_logger. In the DI sanitizer we do some tree walking and have a pretty bad hierarchical log thing. We should switch to tracing so we get proper structured, hierarchical logging.

Improve coverage for BTF generation

Before merging feature/fix-di branch into main, tests needs to be implemented.

For each *relevant type in https://doc.rust-lang.org/reference/types.html and their *relevant combinations:

test proper BTF fn prototype emission
test proper BTF struct/enum emission

*relevant type: no need to cover all types
*relevant combination: no need to cover all combinations

Topic discussed: https://discord.com/channels/855676609003651072/1026937450624450652/1160941939965841509

bpf-linker core dump running pass 'BPF DAG->DAG Pattern Instruction Selection'

cargo xtask build of this program crashes.

#![no_std]
#![no_main]

use aya_ebpf::{
    bindings::xdp_action,
    helpers::bpf_ktime_get_ns,
    macros::{map, xdp},
    maps::LruHashMap,
    programs::XdpContext,
};
use aya_log_ebpf::error;

#[map]
static START: LruHashMap<u32, u64> = LruHashMap::with_max_entries(1 << 10, 0);

#[xdp]
pub fn aya_crash_repro(ctx: XdpContext) -> u32 {
    match try_aya_crash_repro(ctx) {
        Ok(ret) => ret,
        Err(_) => xdp_action::XDP_ABORTED,
    }
}

fn try_aya_crash_repro(ctx: XdpContext) -> Result<u32, u32> {
    let ts = unsafe { bpf_ktime_get_ns() };
    let bucket = 0u32;
    if let Some(start_ts) = unsafe { START.get(&bucket) } {
        let latency = ts - start_ts;
        let bucket_index = latency.ilog2();
        error!(&ctx, "{}", bucket_index);
    }
    Ok(xdp_action::XDP_PASS)
}

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

The output is

error: linking with `bpf-linker` failed: signal: 6 (SIGABRT) (core dumped)
  |
  = note: LC_ALL="C" PATH="/home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/l2dy/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/work/opshell/" VSLANG="1033" "bpf-linker" "--export-symbols" "/tmp/rustcBw2itW/symbols" "/tmp/rustcBw2itW/symbols.o" "/home/l2dy/aya/aya-crash-repro-ebpf/../target/bpfel-unknown-none/debug/deps/aya_crash_repro-0886bd8e8675c312.aya_crash_repro.fc631aa60ebb484-cgu.0.rcgu.o" "-L" "/home/l2dy/aya/aya-crash-repro-ebpf/../target/bpfel-unknown-none/debug/deps" "-L" "/home/l2dy/aya/aya-crash-repro-ebpf/../target/debug/deps" "-L" "/home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/bpfel-unknown-none/lib" "--cpu" "generic" "-L" "/home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/bpfel-unknown-none/lib" "-o" "/home/l2dy/aya/aya-crash-repro-ebpf/../target/bpfel-unknown-none/debug/deps/aya_crash_repro-0886bd8e8675c312" "-O3" "--debug"
  = note: unable to open LLVM shared lib /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-18-rust-1.81.0-nightly.so: /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-18-rust-1.81.0-nightly.so: file too short
          PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
          Stack dump:
          0.    Running pass 'Function Pass Manager' on module 'aya_crash_repro-0886bd8e8675c312'.
          1.    Running pass 'BPF DAG->DAG Pattern Instruction Selection' on function '@aya_crash_repro'

and the crash backtrace is

(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007fd697d80fb3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007fd697d34d96 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007fd697d2026d in __GI_abort () at abort.c:100
#4  0x00007fd693fe79d8 in llvm::report_fatal_error(llvm::Twine const&, bool) () from /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.81.0-nightly
#5  0x00007fd69528297e in llvm::BPFTargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&) const ()
   from /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.81.0-nightly
#6  0x00007fd69629d739 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) [clone .llvm.10772212417860934100] ()
   from /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.81.0-nightly
#7  0x00007fd69629ba37 in llvm::SelectionDAGISel::CodeGenAndEmitDAG() () from /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.81.0-nightly
#8  0x00007fd6962e8b2e in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) ()
   from /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.81.0-nightly
#9  0x00007fd6963f67ce in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) ()
   from /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.81.0-nightly
#10 0x00007fd6962609d4 in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.81.0-nightly
#11 0x00007fd69625fe45 in llvm::FPPassManager::runOnModule(llvm::Module&) () from /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.81.0-nightly
#12 0x00007fd69681fa60 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.81.0-nightly
#13 0x00007fd694e93492 in LLVMTargetMachineEmit(LLVMOpaqueTargetMachine*, LLVMOpaqueModule*, llvm::raw_pwrite_stream&, LLVMCodeGenFileType, char**) ()
   from /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.81.0-nightly
#14 0x00007fd694e93397 in LLVMTargetMachineEmitToFile () from /home/l2dy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.81.0-nightly
#15 0x000055e3fd25eac1 in bpf_linker::llvm::codegen::{closure#0} () at src/llvm/mod.rs:302
#16 bpf_linker::llvm::Message::with<i32, bpf_linker::llvm::codegen::{closure_env#0}> () at src/llvm/mod.rs:350
#17 bpf_linker::llvm::codegen (tm=0x3f81, module=0x3f81, output=..., output_type=llvm_sys::target_machine::LLVMCodeGenFileType::LLVMAssemblyFile) at src/llvm/mod.rs:301
#18 0x000055e3fd2578b1 in bpf_linker::linker::Linker::emit (self=0x7ffd4fcabb90, output=..., output_type=llvm_sys::target_machine::LLVMCodeGenFileType::LLVMObjectFile) at src/linker.rs:505
#19 0x000055e3fd2578b1 in bpf_linker::linker::Linker::codegen (self=0x7ffd4fcabb90)
#20 bpf_linker::linker::Linker::link (self=0x7ffd4fcabb90) at src/linker.rs:268
#21 0x000055e3fd113815 in bpf_linker::main () at src/bin/bpf-linker.rs:285

ilog2 and friends not supported

See #93, which adds a (failing) testcase where LLVM fails to match an instruction.

Dependencies for "external LLVM"

The instructions to use https://github.com/aya-rs/bpf-linker#using-external-llvm are incomplete.

Indeed, in order to compile bpf-linker, I also had to install libpolly-15-dev from https://apt.llvm.org and zlib1g-dev on a Ubuntu 22.04.1 aarch64 virtual machine (on Apple Silicon).

After that, everything is fine and I can test some eBPF programs :)

Fixups for debug_info (to generate BTF acceptable by the kernel)

Related to aya-rs/aya#351

When generating debug_info is enabled in bpf-linker, the produced BTF is not accepted by the kernel. That's because debug_info (and therefore BTF generated from it) is different between the eBPF objects produced by rustc and clang. The long term solution would be getting rid of those differences by making appropriate changes in rustc and LLVM. But for now, we need to do fixups in bpf-linker, to fix the issue faster.

Known differences:

`DW_tag_pointer_type` (in DWARF) / `PTR` (in BTF)

DW_tag_pointer_type produced by rustc:

0x00000369:   DW_TAG_pointer_type
                DW_AT_type      (0x00000376 "i32[1]")
                DW_AT_name      ("*const [i32; 1]")
                DW_AT_address_class     (0x00000000)
[...]
0x00000391:   DW_TAG_pointer_type
                DW_AT_type      (0x0000039e "u32")
                DW_AT_name      ("*const u32")
                DW_AT_address_class     (0x00000000)
[...]
0x000003a5:   DW_TAG_pointer_type
                DW_AT_type      (0x000003b2 "i32[1024]")
                DW_AT_name      ("*const [i32; 1024]")
                DW_AT_address_class     (0x00000000)

PTR BTF produced by rustc:

[1] PTR '*const [i32; 1]' type_id=3
[...]
[5] PTR '*const u32' type_id=6
[...]
[7] PTR '*const [i32; 1024]' type_id=8

DW_tag_pointer_type produced by clang:

0x000000ca:   DW_TAG_pointer_type
                DW_AT_type      (0x000000cf "int[1]")
[...]
0x000000df:   DW_TAG_pointer_type
                DW_AT_type      (0x000000e4 "unsigned int")
[...]
0x000000e8:   DW_TAG_pointer_type
                DW_AT_type      (0x000000ed "int[1024]")

PTR BTF produced by clang:

[1] PTR '(anon)' type_id=3
[...]
[5] PTR '(anon)' type_id=6
[...]
[7] PTR '(anon)' type_id=8

In clang, DW_TAG_pointer_type has only DW_AT_type field, we should probably strip all the others.

`DW_TAG_structure_type` for maps

Not 100% sure if that matters, but in C, maps are defined as anon structs. In Rust, it's impossible to define anon structs, so struct definitions always end up with DW_AT_name.

DWARF produced by rustc:

0x0000002f:     DW_TAG_variable
                  DW_AT_name    ("PID_MAP")
                  DW_AT_type    (0x00000045 "fork::_ty_PID_MAP")
                  DW_AT_external        (true)
                  DW_AT_decl_file       ("/home/vadorovsky/repos/aya-btf-maps/ebpf/fork-ebpf-aya/src/main.rs")
                  DW_AT_decl_line       (12)
                  DW_AT_alignment       (8)
                  DW_AT_location        (DW_OP_addr 0x0)

0x00000045:     DW_TAG_structure_type
                  DW_AT_name    ("_ty_PID_MAP")
                  DW_AT_byte_size       (0x28)
                  DW_AT_alignment       (8)

BTF produced by rustc:

[11] STRUCT '_ty_PID_MAP' size=40 vlen=5
        'type' type_id=1 bits_offset=0
        'key' type_id=5 bits_offset=64
        'value' type_id=5 bits_offset=128
        'max_entries' type_id=7 bits_offset=192
        'map_flags' type_id=9 bits_offset=256

DWARF produced by clang:

0x00000096:   DW_TAG_variable
                DW_AT_name      ("pid_map")
                DW_AT_type      (0x000000a1 "structure ")
                DW_AT_external  (true)
                DW_AT_decl_file ("/home/vadorovsky/repos/aya-btf-maps/ebpf/fork-ebpf-libbpf/fork.bpf.c")
                DW_AT_decl_line (11)
                DW_AT_location  (DW_OP_addrx 0x2)

0x000000a1:   DW_TAG_structure_type
                DW_AT_byte_size (0x20)
                DW_AT_decl_file ("/home/vadorovsky/repos/aya-btf-maps/ebpf/fork-ebpf-libbpf/fork.bpf.c")
                DW_AT_decl_line (6)

BTF produced by clang:

[9] STRUCT '(anon)' size=32 vlen=4
        'type' type_id=1 bits_offset=0
        'key' type_id=5 bits_offset=64
        'value' type_id=5 bits_offset=128
        'max_entries' type_id=7 bits_offset=192

Handle anonymous structs gracefully

When linking bitcode produced by C code with anonymous struct, bpf-linker segfaults on the following line:

bpf-linker/src/llvm/di.rs

Lines 85 to 87 in 60ce107

 let name = CStr::from_ptr(LLVMDITypeGetName(metadata, &mut len)) 

 .to_str() 

 .unwrap();

For anonymous structs, LLVMDITypeGetName(metadata, &mut len) gives a null pointer.

We need to gracefully handle the null pointer case.

Debug info is missing

Hi everyone,

I am writing a perf_event probe and I am using aya-bpf and the bpf-linker. I've used the blueprint build "scripts" from Aya. When I was trying to debug some BPF verifier errors, I tried to get more info on the generated byte code using:

llvm-objdump-16 -S --no-show-raw-insn --section=perf_event target/bpfel-unknown-none/debug/my-bin

However, this does not print the source code, just the byte code:

$ llvm-objdump-16 --source --no-show-raw-insn --section=perf_event target/bpfel-unknown-none/debug/my-bin

target/bpfel-unknown-none/debug/my-bin:	file format elf64-bpf

Disassembly of section perf_event:

0000000000000000 <decode_frame>:
       0:	r6 = r1
       1:	r1 = 0x0
       2:	*(u32 *)(r10 - 0x4) = r1
       3:	r2 = r10
       4:	r2 += -0x4
       5:	r1 = 0x0 ll

I then checked if the binary has debug info at all. Since it didn't, I then changed the Cargo.toml for the ebpf code to have debug = true, but this didn't help as well.

file target/bpfel-unknown-none/debug/my-bin
target/bpfel-unknown-none/debug/my-bin: ELF 64-bit LSB relocatable, eBPF, version 1 (SYSV), not stripped

This is happens on:

$ uname -a
Linux xdp-test 6.2.0-37-generic #38~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov  2 22:07:48 UTC 2 aarch64 aarch64 aarch64 GNU/Linux

(this is a VM running on a macOS on arm).

Cargo and rustc are on 1.73, Aya is pulled directly from github.

Any idea on what might be wrong?

BTF tests are crashing without lto=true

In feature/fix-di branch, BTF tests are crashing the linker when lto=false is passed.

How to replicate: https://github.com/0xrawsec/bpf-linker/tree/bug-lto-flag-btf
Built with LLVM: https://github.com/aya-rs/llvm-project/tree/rustc/16.0-2023-06-05

Backtrace:

#0  llvm::DISubprogram::getLine (this=0x0)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/include/llvm/IR/DebugInfoMetadata.h:1976
1976	  unsigned getLine() const { return Line; }
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/quentin/Workspace/Rust/bpf-linker/target/debug/bpf-linker.
Use `info auto-load python-scripts [REGEXP]' to list them.
gef➤  bt
#0  llvm::DISubprogram::getLine (this=0x0)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/include/llvm/IR/DebugInfoMetadata.h:1976
#1  llvm::BTFDebug::beginInstruction (this=0x5561d7924830, MI=0x5561d757f0b0)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/lib/Target/BPF/BTFDebug.cpp:1372
#2  0x00005561d378f1c7 in llvm::AsmPrinter::emitFunctionBody (this=this@entry=0x5561d7c60f10)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1609
#3  0x00005561d338a605 in llvm::AsmPrinter::runOnMachineFunction (this=0x5561d7c60f10, MF=...)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/include/llvm/CodeGen/AsmPrinter.h:397
#4  0x00005561d383d21b in llvm::MachineFunctionPass::runOnFunction (this=0x5561d7c60f10, F=...)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:91
#5  0x00005561d42b44e0 in llvm::FPPassManager::runOnFunction (this=this@entry=0x5561d8ce1d00, F=...)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1430
#6  0x00005561d42ba441 in llvm::FPPassManager::runOnModule (this=0x5561d8ce1d00, M=...)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1476
#7  0x00005561d42b4ac5 in (anonymous namespace)::MPPassManager::runOnModule (this=0x5561d79845e0, 
    M=...)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1545
#8  llvm::legacy::PassManagerImpl::run (this=0x5561d76feac0, M=...)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/lib/IR/LegacyPassManager.cpp:535
#9  0x00005561d39112a4 in LLVMTargetMachineEmit (T=T@entry=0x5561d805c770, M=M@entry=0x5561d7311150, 
    OS=..., codegen=codegen@entry=LLVMObjectFile, ErrorMessage=ErrorMessage@entry=0x7fffec7e6dc8)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/lib/Target/TargetMachineC.cpp:210
#10 0x00005561d3911154 in LLVMTargetMachineEmitToFile (T=0x5561d805c770, M=0x5561d7311150, 
    Filename=0x5561d7e21270 "/tmp/assembly/basic.s", codegen=LLVMObjectFile, 
    ErrorMessage=0x7fffec7e6dc8)
    at /home/quentin/Workspace/Rust/custom-bpf-linker/aya-llvm-project/llvm/lib/Target/TargetMachineC.cpp:226
#11 0x00005561d335fc1b in bpf_linker::llvm::codegen::{closure#0} (message=0x7fffec7e6dc8)
    at src/llvm/mod.rs:275
#12 0x00005561d3360040 in bpf_linker::llvm::Message::with<i32, bpf_linker::llvm::codegen::{closure_env#0}> (f=...) at src/llvm/mod.rs:323
#13 0x00005561d3356538 in bpf_linker::llvm::codegen (tm=0x5561d805c770, module=0x5561d7311150, 
    output=..., output_type=llvm_sys::target_machine::LLVMCodeGenFileType::LLVMObjectFile)
    at src/llvm/mod.rs:274
#14 0x00005561d333aeca in bpf_linker::linker::Linker::emit (self=0x7fffec7e84c0, output=..., 
    output_type=llvm_sys::target_machine::LLVMCodeGenFileType::LLVMObjectFile) at src/linker.rs:490
#15 0x00005561d333aac1 in bpf_linker::linker::Linker::codegen (self=0x7fffec7e84c0)
    at src/linker.rs:467
#16 0x00005561d3337e21 in bpf_linker::linker::Linker::link (self=0x7fffec7e84c0) at src/linker.rs:262
#17 0x00005561d32fec7d in bpf_linker::main () at src/bin/bpf-linker.rs:269
#18 0x00005561d33186cb in core::ops::function::FnOnce::call_once<fn(), ()> ()
    at /rustc/864bdf7843e1ceabc824ed86d97006acad6af643/library/core/src/ops/function.rs:250
#19 0x00005561d3311a9e in std::sys_common::backtrace::__rust_begin_short_backtrace<fn(), ()> (
    f=0x5561d32fd8e0 <bpf_linker::main>)
    at /rustc/864bdf7843e1ceabc824ed86d97006acad6af643/library/std/src/sys_common/backtrace.rs:135
#20 0x00005561d332a9f0 in std::rt::lang_start::{closure#0}<()> ()
    at /rustc/864bdf7843e1ceabc824ed86d97006acad6af643/library/std/src/rt.rs:166
#21 0x00005561d4e5ff4b in core::ops::function::impls::{impl#2}::call_once<(), (dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> ()
    at library/core/src/ops/function.rs:284
#22 std::panicking::try::do_call<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> () at library/std/src/panicking.rs:524
#23 std::panicking::try<i32, &(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> () at library/std/src/panicking.rs:488
#24 std::panic::catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> () at library/std/src/panic.rs:142
#25 std::rt::lang_start_internal::{closure#2} () at library/std/src/rt.rs:148
#26 std::panicking::try::do_call<std::rt::lang_start_internal::{closure_env#2}, isize> ()
    at library/std/src/panicking.rs:524
#27 std::panicking::try<isize, std::rt::lang_start_internal::{closure_env#2}> ()
    at library/std/src/panicking.rs:488
#28 std::panic::catch_unwind<std::rt::lang_start_internal::{closure_env#2}, isize> ()
    at library/std/src/panic.rs:142
#29 std::rt::lang_start_internal () at library/std/src/rt.rs:148
#30 0x00005561d332a9ca in std::rt::lang_start<()> (main=0x5561d32fd8e0 <bpf_linker::main>, argc=0x22, 
    argv=0x7fffec7e8bd8, sigpipe=0x0)
    at /rustc/864bdf7843e1ceabc824ed86d97006acad6af643/library/std/src/rt.rs:165
#31 0x00005561d3305b2e in main ()
#32 0x00007f6fec439850 in ?? () from /usr/lib/libc.so.6
#33 0x00007f6fec43990a in __libc_start_main () from /usr/lib/libc.so.6
#34 0x00005561d32f8bc5 in _start ()
```

`bpf-linker` panics with `Unable to open LLVM shared lib: [...]/libLLVM-18-rust-1.79.0-nightly.so: file too short`

Hi,

When trying to compile https://github.com/aya-rs/book/tree/1d62046f4addf513ceb29298e38116625e776a3e/examples/xdp-hello cargo xtask build-ebpf panics with Unable to open LLVM shared lib: [...]/libLLVM-18-rust-1.79.0-nightly.so: file too short, see full stack trace below. I am not sure if this could be related to #210, the stack trace contains a similar top error, but it looks a bit different. Thanks!

cc @rdelfin

Full stacktrace

error: linking with `bpf-linker` failed: exit status: 101
  |
  = note: LC_ALL="C" PATH="/home/javierhonduco/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/javierhonduco/.bun/bin:/usr/local/go/bin:/usr/lib/golang/bin/go:/home/javierhonduco/.rbenv/bin:/home/javierhonduco/.rbenv/shims:/home/javierhonduco/.rbenv/bin:/home/javierhonduco/go/bin:/home/javierhonduco/.nvm/versions/node/v16.13.0/bin:/home/javierhonduco/.cargo/bin:/home/javierhonduco/.local/bin:/home/javierhonduco/bin:/home/javierhonduco/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin" VSLANG="1033" "bpf-linker" "--export-symbols" "/tmp/rustcwjYinT/symbols" "/tmp/rustcwjYinT/symbols.o" "/home/javierhonduco/src/book/examples/xdp-hello/xdp-hello-ebpf/../target/bpfel-unknown-none/debug/deps/xdp_hello-10a2003513780c7c.xdp_hello.b94140af8b949ec1-cgu.0.rcgu.o" "-L" "/home/javierhonduco/src/book/examples/xdp-hello/xdp-hello-ebpf/../target/bpfel-unknown-none/debug/deps" "-L" "/home/javierhonduco/src/book/examples/xdp-hello/xdp-hello-ebpf/../target/debug/deps" "-L" "/home/javierhonduco/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/bpfel-unknown-none/lib" "--cpu" "generic" "-L" "/home/javierhonduco/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/bpfel-unknown-none/lib" "-o" "/home/javierhonduco/src/book/examples/xdp-hello/xdp-hello-ebpf/../target/bpfel-unknown-none/debug/deps/xdp_hello-10a2003513780c7c" "-O3" "--debug"
  = note: Unable to open LLVM shared lib: /home/javierhonduco/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-18-rust-1.79.0-nightly.so: file too short
          thread 'main' panicked at 'explicit panic', /home/javierhonduco/.cargo/registry/src/github.com-1ecc6299db9ec823/aya-rustc-llvm-proxy-0.4.0/src/lib.rs:75:17
          stack backtrace:
             0:     0x5599fa576eed - std::backtrace_rs::backtrace::libunwind::trace::h22893a5306c091b4
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
             1:     0x5599fa576eed - std::backtrace_rs::backtrace::trace_unsynchronized::h29c3bc6f9e91819d
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
             2:     0x5599fa576eed - std::sys_common::backtrace::_print_fmt::he497d8a0ec903793
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:66:5
             3:     0x5599fa576eed - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h9c2a9d2774d81873
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:45:22
             4:     0x5599fa5938fc - core::fmt::write::hba4337c43d992f49
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/fmt/mod.rs:1194:17
             5:     0x5599fa5745f1 - std::io::Write::write_fmt::heb73de6e02cfabed
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/io/mod.rs:1655:15
             6:     0x5599fa578845 - std::sys_common::backtrace::_print::h63c8b24acdd8e8ce
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:48:5
             7:     0x5599fa578845 - std::sys_common::backtrace::print::h426700d6240cdcc2
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:35:9
             8:     0x5599fa578845 - std::panicking::default_hook::{{closure}}::hc9a76eed0b18f82b
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:295:22
             9:     0x5599fa5784f9 - std::panicking::default_hook::h2e88d02087fae196
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:314:9
            10:     0x5599fa578d92 - std::panicking::rust_panic_with_hook::habfdcc2e90f9fd4c
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:698:17
            11:     0x5599fa55ad5b - std::panicking::begin_panic::{{closure}}::h835707b40f64487e
            12:     0x5599fa55ad24 - std::sys_common::backtrace::__rust_end_short_backtrace::h79d28ddfc213af0f
            13:     0x5599fa4ce17a - std::panicking::begin_panic::h7328ce24b96cb83d
            14:     0x5599fa558f01 - std::sync::once::Once::call_once::{{closure}}::h41b21e1b69140d08
            15:     0x5599fa4cf12a - std::sync::once::Once::call_inner::h8b7937883f1da40f
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sync/once.rs:434:21
            16:     0x5599fa55754e - LLVMInitializeBPFTarget
            17:     0x5599fa4f22e0 - bpf_linker::llvm::init::h5dc90320967e0641
            18:     0x5599fa4ecdda - bpf_linker::linker::Linker::link::h3f937367f1914f40
            19:     0x5599fa4e4f0d - bpf_linker::main::hf636bd6a42f47524
            20:     0x5599fa4eaae3 - std::sys_common::backtrace::__rust_begin_short_backtrace::h2cada9d54d4f7eef
            21:     0x5599fa4d8f19 - std::rt::lang_start::{{closure}}::h9cbc01e35539e700
            22:     0x5599fa56e9fe - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::had4f69b3aefb47a8
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/ops/function.rs:259:13
            23:     0x5599fa56e9fe - std::panicking::try::do_call::hf2ad5355fcafe775
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:492:40
            24:     0x5599fa56e9fe - std::panicking::try::h0a63ac363423e61e
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:456:19
            25:     0x5599fa56e9fe - std::panic::catch_unwind::h18088edcecb8693a
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panic.rs:137:14
            26:     0x5599fa56e9fe - std::rt::lang_start_internal::{{closure}}::ha7dad166dc711761
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/rt.rs:128:48
            27:     0x5599fa56e9fe - std::panicking::try::do_call::hda0c61bf3a57d6e6
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:492:40
            28:     0x5599fa56e9fe - std::panicking::try::hbc940e68560040a9
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:456:19
            29:     0x5599fa56e9fe - std::panic::catch_unwind::haed0df2aeb3fa368
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panic.rs:137:14
            30:     0x5599fa56e9fe - std::rt::lang_start_internal::h9c06694362b5b80c
                                         at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/rt.rs:128:20
            31:     0x5599fa4e5722 - main
            32:     0x7f217c0e0088 - __libc_start_call_main
            33:     0x7f217c0e014b - __libc_start_main_impl
            34:     0x5599fa4cfa65 - _start
            35:                0x0 - <unknown>

Environment info

[javierhonduco@fedora xdp-hello]$ file /home/javierhonduco/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-18-rust-1.79.0-nightly.so
/home/javierhonduco/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-18-rust-1.79.0-nightly.so: ASCII text

[javierhonduco@fedora xdp-hello]$ cat /home/javierhonduco/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-18-rust-1.79.0-nightly.so
INPUT(libLLVM.so.18.1-rust-1.79.0-nightly)

/home/javierhonduco/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.79.0-nightly: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

[javierhonduco@fedora xdp-hello]$ ls -lah /home/javierhonduco/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.79.0-nightly`
-rw-r--r--. 1 javierhonduco javierhonduco 139M Apr 25 11:38 /home/javierhonduco/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM.so.18.1-rust-1.79.0-nightly

[javierhonduco@fedora xdp-hello]$ rustc --version
rustc 1.79.0-nightly (ef8b9dcf2 2024-04-24)

[javierhonduco@fedora xdp-hello]$ cat /etc/os-release
NAME="Fedora Linux"
VERSION="40 (Workstation Edition)"
ID=fedora
VERSION_ID=40
VERSION_CODENAME=""
PLATFORM_ID="platform:f40"
PRETTY_NAME="Fedora Linux 40 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:40"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=40
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=40
SUPPORT_END=2025-05-13
VARIANT="Workstation Edition"
VARIANT_ID=workstation

[javierhonduco@fedora xdp-hello]$ bpf-linker --version
bpf-linker 0.9.4

bpf-linker core dump in aya-template generated project

This is my rustc version:

Default host: x86_64-unknown-linux-gnu
rustup home:  /home/cfeitong/.rustup

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.58.0-nightly (dd549dcab 2021-11-25)

I just run cargo xtask build-ebpf and come across following error:

cargo xtask build-ebpf
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/xtask build-ebpf`
       Fresh core v0.0.0 (/home/cfeitong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
       Fresh unicode-xid v0.2.2
       Fresh rustc-std-workspace-core v1.99.0 (/home/cfeitong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
       Fresh compiler_builtins v0.1.52
       Fresh proc-macro2 v1.0.32
       Fresh quote v1.0.10
       Fresh aya-bpf-cty v0.2.1 (http://github.com/aya-rs/aya?branch=main#98b36b23)
       Fresh aya-try-common v0.1.0 (/home/cfeitong/aya-try/aya-try-common)
       Fresh syn v1.0.82
       Fresh aya-bpf-bindings v0.1.0 (http://github.com/aya-rs/aya?branch=main#98b36b23)
       Fresh aya-bpf-macros v0.1.0 (http://github.com/aya-rs/aya?branch=main#98b36b23)
       Fresh aya-bpf v0.1.0 (http://github.com/aya-rs/aya?branch=main#98b36b23)
   Compiling aya-try-ebpf v0.1.0 (/home/cfeitong/aya-try/aya-try-ebpf)
     Running `rustc --crate-name aya_try --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C opt-level=2 -C panic=abort -C embed-bitcode=no -C debuginfo=1 -C debug-assertions=on -C overflow-checks=off -C metadata=36fb82a4cf69a379 -C extra-filename=-36fb82a4cf69a379 --out-dir /home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps --target bpfel-unknown-none -C incremental=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/incremental -L dependency=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps -L dependency=/home/cfeitong/aya-try/aya-try-ebpf/../target/debug/deps --extern aya_bpf=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps/libaya_bpf-54640d6e071de353.rlib --extern aya_try_common=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps/libaya_try_common-356f6b2922032732.rlib --extern 'noprelude:compiler_builtins=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps/libcompiler_builtins-177c1b24e4b8b2db.rlib' --extern 'noprelude:core=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps/libcore-2c13aef38b676b75.rlib' -Z unstable-options`
error: linking with `bpf-linker` failed: signal: 6 (core dumped)
  |
  = note: "bpf-linker" "--export-symbols" "/tmp/rustcgdWOgi/symbols" "/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps/aya_try-36fb82a4cf69a379.17dzbhexels5i7io.rcgu.o" "-L" "/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps" "-L" "/home/cfeitong/aya-try/aya-try-ebpf/../target/debug/deps" "-L" "/home/cfeitong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/bpfel-unknown-none/lib" "/home/cfeitong/aya-try/target/bpfel-unknown-none/debug/deps/libaya_bpf-54640d6e071de353.rlib" "/home/cfeitong/aya-try/target/bpfel-unknown-none/debug/deps/libaya_bpf_bindings-be43530adef294a6.rlib" "/home/cfeitong/aya-try/target/bpfel-unknown-none/debug/deps/libaya_bpf_cty-b7d399661acdd31b.rlib" "/home/cfeitong/aya-try/target/bpfel-unknown-none/debug/deps/librustc_std_workspace_core-51eb0738dcf81a45.rlib" "/home/cfeitong/aya-try/target/bpfel-unknown-none/debug/deps/libcore-2c13aef38b676b75.rlib" "/home/cfeitong/aya-try/target/bpfel-unknown-none/debug/deps/libcompiler_builtins-177c1b24e4b8b2db.rlib" "--cpu" "generic" "--cpu-features" "" "-L" "/home/cfeitong/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/bpfel-unknown-none/lib" "-o" "/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps/aya_try-36fb82a4cf69a379" "-O2" "--debug"
  = note: 09:11:02 [ERROR] fatal error: "Cannot select: 0x55f68fc8fd58: i64,ch = AtomicLoad<(load unordered (s64) from %ir.45)> 0x55f68e76e978, 0x55f68fc90100\n  0x55f68fc90100: i64,ch = CopyFromReg 0x55f68e76e978, Register:i64 %19\n    0x55f68fc904a8: i64 = Register %19\nIn function: memcpy"
          PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
          Stack dump:
          0.    Running pass 'Function Pass Manager' on module 'aya_try-36fb82a4cf69a379'.
          1.    Running pass 'BPF DAG->DAG Pattern Instruction Selection' on function '@memcpy'
          

error: could not compile `aya-try-ebpf` due to previous error

Caused by:
  process didn't exit successfully: `rustc --crate-name aya_try --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C opt-level=2 -C panic=abort -C embed-bitcode=no -C debuginfo=1 -C debug-assertions=on -C overflow-checks=off -C metadata=36fb82a4cf69a379 -C extra-filename=-36fb82a4cf69a379 --out-dir /home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps --target bpfel-unknown-none -C incremental=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/incremental -L dependency=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps -L dependency=/home/cfeitong/aya-try/aya-try-ebpf/../target/debug/deps --extern aya_bpf=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps/libaya_bpf-54640d6e071de353.rlib --extern aya_try_common=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps/libaya_try_common-356f6b2922032732.rlib --extern 'noprelude:compiler_builtins=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps/libcompiler_builtins-177c1b24e4b8b2db.rlib' --extern 'noprelude:core=/home/cfeitong/aya-try/aya-try-ebpf/../target/bpfel-unknown-none/debug/deps/libcore-2c13aef38b676b75.rlib' -Z unstable-options` (exit status: 1)
thread 'main' panicked at 'assertion failed: status.success()', xtask/src/build_ebpf.rs:62:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

v0.9.12 fails to build with rust 1.80.0

Due to a build regression in rust 1.80.0, the time crate has to be updated to fix the build. I see that the fix is already pulled in at 1e70f60, however it's not yet available in a released version of bpf-linker, thus asking for a new release containing the fix if possible.

Assembly tests are crashing linker when sysroot is built with DI

In feature/fix-di branch, when test sysroot is built with DI almost all assembly tests are crashing the linker.

How to replicate: https://github.com/0xrawsec/bpf-linker/tree/bug-assembly-di
Built with LLVM: https://github.com/aya-rs/llvm-project/tree/rustc/16.0-2023-06-05

running 6 tests
test [assembly] assembly/di_generics.rs ... ok
test [assembly] assembly/elf-sections.rs ... FAILED
test [assembly] assembly/unroll-loop.rs ... ignored
test [assembly] assembly/bin.rs ... FAILED
test [assembly] assembly/ignore-inline-never.rs ... FAILED
test [assembly] assembly/re-export-symbols.rs ... FAILED

After a brief analysis, all seems to be linked to a known LLVM bug. Here is an example of the backtrace:

#0  llvm::DISubprogram::getLine (this=0x0)
    at custom-bpf-linker/aya-llvm-project/llvm/include/llvm/IR/DebugInfoMetadata.h:1976
#1  llvm::BTFDebug::beginInstruction (this=0x55d8122095a0, MI=0x55d81258fc08)
    at custom-bpf-linker/aya-llvm-project/llvm/lib/Target/BPF/BTFDebug.cpp:1372
#2  0x000055d80e2701c7 in llvm::AsmPrinter::emitFunctionBody (this=this@entry=0x55d8112c6950)
    at custom-bpf-linker/aya-llvm-project/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1609
#3  0x000055d80de6b605 in llvm::AsmPrinter::runOnMachineFunction (this=0x55d8112c6950, MF=...)
    at custom-bpf-linker/aya-llvm-project/llvm/include/llvm/CodeGen/AsmPrinter.h:397
#4  0x000055d80e31e21b in llvm::MachineFunctionPass::runOnFunction (this=0x55d8112c6950, F=...)
    at custom-bpf-linker/aya-llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:91
#5  0x000055d80ed954e0 in llvm::FPPassManager::runOnFunction (this=this@entry=0x55d8144c4e50, F=...)
    at custom-bpf-linker/aya-llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1430
#6  0x000055d80ed9b441 in llvm::FPPassManager::runOnModule (this=0x55d8144c4e50, M=...)
    at custom-bpf-linker/aya-llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1476
#7  0x000055d80ed95ac5 in (anonymous namespace)::MPPassManager::runOnModule (this=0x55d811ca9130, 
    M=...)
    at custom-bpf-linker/aya-llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1545
#8  llvm::legacy::PassManagerImpl::run (this=0x55d811119a50, M=...)
    at custom-bpf-linker/aya-llvm-project/llvm/lib/IR/LegacyPassManager.cpp:535
#9  0x000055d80e3f22a4 in LLVMTargetMachineEmit (T=T@entry=0x55d8136a8ab0, M=M@entry=0x55d810ab0150, 
    OS=..., codegen=codegen@entry=LLVMAssemblyFile, ErrorMessage=ErrorMessage@entry=0x7fffd901aad8)
    at custom-bpf-linker/aya-llvm-project/llvm/lib/Target/TargetMachineC.cpp:210
#10 0x000055d80e3f2154 in LLVMTargetMachineEmitToFile (T=0x55d8136a8ab0, M=0x55d810ab0150, 
    Filename=0x55d8141a7640 "/tmp/bin.s", codegen=LLVMAssemblyFile, ErrorMessage=0x7fffd901aad8)
    at custom-bpf-linker/aya-llvm-project/llvm/lib/Target/TargetMachineC.cpp:226
#11 0x000055d80de40c1b in bpf_linker::llvm::codegen::{closure#0} (message=0x7fffd901aad8)
    at src/llvm/mod.rs:275
#12 0x000055d80de41040 in bpf_linker::llvm::Message::with<i32, bpf_linker::llvm::codegen::{closure_env#0}> (f=...) at src/llvm/mod.rs:323
#13 0x000055d80de37538 in bpf_linker::llvm::codegen (tm=0x55d8136a8ab0, module=0x55d810ab0150, 
    output=..., output_type=llvm_sys::target_machine::LLVMCodeGenFileType::LLVMAssemblyFile)
    at src/llvm/mod.rs:274
#14 0x000055d80de1beca in bpf_linker::linker::Linker::emit (self=0x7fffd901c1d0, output=..., 
    output_type=llvm_sys::target_machine::LLVMCodeGenFileType::LLVMAssemblyFile) at src/linker.rs:490
#15 0x000055d80de1ba75 in bpf_linker::linker::Linker::codegen (self=0x7fffd901c1d0)
    at src/linker.rs:466
#16 0x000055d80de18e21 in bpf_linker::linker::Linker::link (self=0x7fffd901c1d0) at src/linker.rs:262
#17 0x000055d80dddfc7d in bpf_linker::main () at src/bin/bpf-linker.rs:269
#18 0x000055d80ddf96cb in core::ops::function::FnOnce::call_once<fn(), ()> ()
    at /rustc/864bdf7843e1ceabc824ed86d97006acad6af643/library/core/src/ops/function.rs:250
#19 0x000055d80ddf2a9e in std::sys_common::backtrace::__rust_begin_short_backtrace<fn(), ()> (
    f=0x55d80ddde8e0 <bpf_linker::main>)
    at /rustc/864bdf7843e1ceabc824ed86d97006acad6af643/library/std/src/sys_common/backtrace.rs:135
#20 0x000055d80de0b9f0 in std::rt::lang_start::{closure#0}<()> ()
    at /rustc/864bdf7843e1ceabc824ed86d97006acad6af643/library/std/src/rt.rs:166
#21 0x000055d80f940f4b in core::ops::function::impls::{impl#2}::call_once<(), (dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> ()
    at library/core/src/ops/function.rs:284
#22 std::panicking::try::do_call<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> () at library/std/src/panicking.rs:524
#23 std::panicking::try<i32, &(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> () at library/std/src/panicking.rs:488
#24 std::panic::catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> () at library/std/src/panic.rs:142
#25 std::rt::lang_start_internal::{closure#2} () at library/std/src/rt.rs:148
#26 std::panicking::try::do_call<std::rt::lang_start_internal::{closure_env#2}, isize> ()
    at library/std/src/panicking.rs:524
#27 std::panicking::try<isize, std::rt::lang_start_internal::{closure_env#2}> ()
    at library/std/src/panicking.rs:488
#28 std::panic::catch_unwind<std::rt::lang_start_internal::{closure_env#2}, isize> ()
    at library/std/src/panic.rs:142
#29 std::rt::lang_start_internal () at library/std/src/rt.rs:148
#30 0x000055d80de0b9ca in std::rt::lang_start<()> (main=0x55d80ddde8e0 <bpf_linker::main>, argc=0x23, 
    argv=0x7fffd901c8e8, sigpipe=0x0)
    at /rustc/864bdf7843e1ceabc824ed86d97006acad6af643/library/std/src/rt.rs:165
#31 0x000055d80dde6b2e in main ()
#32 0x00007f4ba9e39850 in ?? () from /usr/lib/libc.so.6
#33 0x00007f4ba9e3990a in __libc_start_main () from /usr/lib/libc.so.6
#34 0x000055d80ddd9bc5 in _start ()

Strip away debug info not needed by BPF programs (and subprograms used by them)

Currently, when we link bitcodes with debug info, even though we fix up it, we don't strip it. That produces a lot of unnecessary DI.

For example, if lto is not used, the debug info of core crate and other dependencies will end up in the BTF too. That makes the BTF relocations and program verification slower. It's also not correct by principle.

Context: https://discord.com/channels/855676609003651072/1026937450624450652/1133054554666180678

	let name = CStr::from_ptr(LLVMDITypeGetName(metadata, &mut len))
	.to_str()
	.unwrap();

aya-rs / bpf-linker Goto Github PK

bpf-linker's People

Contributors

Stargazers

Watchers

Forkers

bpf-linker's Issues

Solution

DW_tag_pointer_type (in DWARF) / PTR (in BTF)

DW_TAG_structure_type for maps

Full stacktrace

Environment info

Recommend Projects

Recommend Topics

Recommend Org

Jobs

`DW_tag_pointer_type` (in DWARF) / `PTR` (in BTF)

`DW_TAG_structure_type` for maps