Re: [PATCH bpf-next v2 4/4] resolve_btfids: change in-place update with raw binary output

From: Ihor Solodrai

Date: Wed Dec 03 2025 - 23:42:48 EST


On 12/3/25 10:48 AM, Alan Maguire wrote:
> On 01/12/2025 22:16, Andrii Nakryiko wrote:
>> On Thu, Nov 27, 2025 at 10:53 AM Ihor Solodrai <ihor.solodrai@xxxxxxxxx> wrote:
>>
>> [...]
>>
>>> +if ! is_enabled CONFIG_DEBUG_INFO_BTF; then
>>> + exit 0
>>> +fi
>>> +
>>> +gen_btf_data()
>>> +{
>>> + info BTF "${ELF_FILE}"
>>> + btf1="${ELF_FILE}.btf.1"
>>> + ${PAHOLE} -J ${PAHOLE_FLAGS} \
>>> + ${BTF_BASE:+--btf_base ${BTF_BASE}} \
>>> + --btf_encode_detached=${btf1} \
>>
>> please double-check what pahole version has --btf_encode_detached, we
>> might need to change minimal supported pahole version because of this
>>
>
> yeah, this landed in v1.22 [1]

Thank you for checking!

>
> One thing worth thinking about; are there aspects of the gen_btf.sh
> script that could be moved to Makefile.btf to avoid having to compute them
> repeatedly for each module? For example computing resolve_btfids
> flags based on CONFIG_WERROR could be done there I think. You could
> also determine whether the script is needed at all in Makefile.btf; i.e.
>
> gen-btf-y =
> gen-btf-$(CONFIG_DEBUG_INFO_BTF) = scripts/gen-btf.sh
>
> export GEN_BTF := $(gen-btf-y)
>
> That would allow you to get rid of the is_enabled() I think.

Good point. I'll try moving most relevant flags to Makefile.btf

>
> I'm building this now, but I was wondering if the linking/objcopy changes pose
> any risk to kernel address computations in kallsyms or anything like that? IIRC
> Stephen ran into some issues with global variable addresses as a consequence of
> linking BTF sections [2], but not sure if there are additional concerns here.

This series doesn't change the fact that .BTF is *linked* into final vmlinux,
so a problem described in [2] stands.

That said, AFAIU the suggested change in the linker script will still work.

>
> [1] https://github.com/acmel/dwarves/releases/tag/v1.22
> [2] https://lore.kernel.org/bpf/20250207012045.2129841-2-stephen.s.brennan@xxxxxxxxxx/