Re: Linking BTF

["Jose E. Marchesi" <jose.marchesi@oracle.com>]

> On Wed, 2025-07-16 at 16:15 +0100, Nick Alcock wrote:
>
> [...]
>
>>  - So... a third option, which is probably the most BTFish because it's
>>    something BTF already does, in a sense: put everything in one section,
>>    call it .BTF or .BTFA or whatever, and make that section an archive of
>>    named BTF members, and then stuff however many BTF outputs the
>>    deduplication generates (or none, if we're just stuffing inputs into
>>    outputs without dedupping) into archive members.
>> 
>> So, here's a possibility which seems to provide the latter option while
>> still letting existing tools read the first member (likely vmlinux):
>> 
>> The idea is that we add a *next member link field* in the BTF header, and a
>> name (a strtab offset).  The next member link field is an end-of-header-
>> relative offset just like most of the other header fields, which chains BTF
>> members together in a linked list:
>> 
>> parent     BTF
>>             |
>>             v
>> children   BTF -> BTF -> BTF -> ... -> BTF
>> 
>> The parent is always first in the list.
>
> Hi Nick,
>
> You are talking about BTF section embedded in a final vmlinux binary, right?

More generally, a section embedded in any object which is the result of
linking two or more objects having .BTF sections:

  ld foo.o (.BTF) bar.o (.BTF) -> baz.o (.BTF)

This covers the particular vmlinux case I think.

> Could you please elaborate a bit on why do you need multiple members
> within this section (in the context of your third option)?
> I re-read the email but don't get it :(

As I understand it:

The linker deduplicates types in the set of input .BTF sections.  This
means that when linking foo.o and bar.o, if both compilation units refer
to a type 'quux', there are two possibilities:

a) The type 'quux' is the same (using C type equivalence rules) in both
   compilation units.  Then the type is "shared" and the linker puts it
   only once in the first output BTF member in baz.o .BTF, the "parent".

b) The type 'quux' is different in both compilation units.  These are
   then conflicting types.  Then two versions the type, foo.quux and
   bar.quux, are placed by the linker in the corresponding "children"
   member in baz.o.

Graphically, the .BTF section in a linked binary would contain a
one-level tree of members, with as many children as input compilation
units :


    parent (common types)
      |
      +---  child1 (types only in child1)
      +---  child2 (types only in child2)
      .
      +---  childN (types only in childN)

Hope this makes sense.  Nick should be able to explain it better than I
do.