[lld] [llvm] [lld][DebugInfo/BTF] Add BTF section merging and deduplication (PR #183915)

[Peter Smith via llvm-commits]

https://github.com/smithp35 commented:

> the motivation is thin: "enabling the LTO + Rust + BTF pipeline in the Linux kernel" needs more context — what specifically was broken or missing?
> 

Closest external link I can find about this is https://lwn.net/Articles/991719/ "BTF, Rust, and the kernel toolchain"

Apologies in advance for naive questions about btf.

While I can get that an external tool to translate DWARF isn't the ideal architecture, has there been any consideration been given to updating pahole to filter out the Rust DWARF information that cannot be represented?

Are there any plans to implement this option in ld.bfd? Sure it won't support Rust/LTO (at least not yet), but parity between the toolchains to avoid pahole seems like a good idea.

> If the lld implementation is a thin wrapper of DebugInfoBTF, it doesn't need so many tests.
> 
> The five test .s files (btf-merge-basic.s, btf-merge-dedup.s, btf-merge-single.s, btf-merge-struct.s) embed near-identical BTF bytes inline. Can they be restructured and grouped to a small set of tests? If you read test history in this directory, I have many refactoring patches that group related tests with `split-file`. Newer tests tend to not use `Inputs/` at all. The lack of a dump tool is also a problem. Dumping the section content as hex in lld/test/ELF is not ideal. Most tests should be on the LLVM BTF side.
> 
> In addition we should have -r and --gc-sections tests. `-` should not merge the section contents.

I agree with the sentiment that human readable dump output would help a lot. That may even enable bits of this patch to be split up into smaller parts that can be reviewed independently.

I note that GNU objdump https://sourceware.org/binutils/docs/binutils/objdump.html#index-CTF has some support for ctf output . Could that be used/extended to btf and implemented?



https://github.com/llvm/llvm-project/pull/183915