On Mon, Apr 28, 2025 at 04:36:07PM -0300, Arnaldo Carvalho de Melo wrote:
> On Mon, Apr 28, 2025 at 04:21:14PM +0100, Alan Maguire wrote:
> > In the bad case, the bpf_prog active member:
>
> > <2><3d594>: Abbrev Number: 4 (DW_TAG_member)
> > <3d595> DW_AT_name : (indirect string, offset: 0x3b976): active
> > <3d599> DW_AT_decl_file : 125
> > <3d59a> DW_AT_decl_line : 1654
> > <3d59c> DW_AT_decl_column : 17
> > <3d59d> DW_AT_type : <0x4bd05>
>
> > ...is a pointer:
> >
> > <1><4bd05>: Abbrev Number: 58 (DW_TAG_pointer_type)
> > <4bd06> DW_AT_byte_size : 8
> > <4bd07> DW_AT_address_class: 2
> > <4bd08> DW_AT_type : <0x301cd>
>
> > ...which points at an int
>
> > <1><301cd>: Abbrev Number: 214 (DW_TAG_base_type)
> > <301cf> DW_AT_byte_size : 4
> > <301d0> DW_AT_encoding : 5 (signed)
> > <301d1> DW_AT_name : int
> > <301d5> DW_AT_name : int
>
> > ...but note the the DW_AT_address_class attribute in the latter case and
> > the two DW_AT_name values. We don't use that address attribute in pahole
> > as far as I can see, but it might be enough to cause problems.
I just looked at a vmlinux built with gcc 15 and we have those:
<1><7812a39>: Abbrev Number: 7 (DW_TAG_structure_type)
<7812a3a> DW_AT_name : (indirect string, offset: 0xc0e4): alloc_tag_counters
<7812a3e> DW_AT_byte_size : 16
<7812a3f> DW_AT_decl_file : 76
<7812a40> DW_AT_decl_line : 18
<7812a41> DW_AT_decl_column : 8
<7812a42> DW_AT_sibling : <0x7812a61>
<2><7812a46>: Abbrev Number: 1 (DW_TAG_member)
<7812a47> DW_AT_name : (indirect string, offset: 0x3c288f): bytes
<7812a4b> DW_AT_decl_file : 76
<7812a4c> DW_AT_decl_line : 19
<7812a4d> DW_AT_decl_column : 6
<7812a4e> DW_AT_type : <0x780f217>
<7812a52> DW_AT_data_member_location: 0
<2><7812a53>: Abbrev Number: 1 (DW_TAG_member)
<7812a54> DW_AT_name : (indirect string, offset: 0x255770): calls
<7812a58> DW_AT_decl_file : 76
<7812a59> DW_AT_decl_line : 20
<7812a5a> DW_AT_decl_column : 6
<7812a5b> DW_AT_type : <0x780f217>
<7812a5f> DW_AT_data_member_location: 8
<1><7812a88>: Abbrev Number: 80 (DW_TAG_pointer_type)
<7812a89> DW_AT_byte_size : 8
<7812a89> DW_AT_address_class: 2
<7812a89> DW_AT_type : <0x7812a39>
<1><7812a61>: Abbrev Number: 25 (DW_TAG_structure_type)
<7812a62> DW_AT_name : (indirect string, offset: 0x585bd1): alloc_tag
<7812a66> DW_AT_byte_size : 40
<7812a67> DW_AT_alignment : 8
<7812a68> DW_AT_decl_file : 76
<7812a69> DW_AT_decl_line : 28
<7812a6a> DW_AT_decl_column : 8
<7812a6a> DW_AT_sibling : <0x7812a88>
<2><7812a6e>: Abbrev Number: 54 (DW_TAG_member)
<7812a6f> DW_AT_name : ct
<7812a72> DW_AT_decl_file : 76
<7812a73> DW_AT_decl_line : 29
<7812a74> DW_AT_decl_column : 19
<7812a75> DW_AT_type : <0x78129ea>
<7812a79> DW_AT_alignment : 8
<7812a79> DW_AT_data_member_location: 0
<2><7812a7a>: Abbrev Number: 1 (DW_TAG_member)
<7812a7b> DW_AT_name : (indirect string, offset: 0x565566): counters
<7812a7f> DW_AT_decl_file : 76
<7812a80> DW_AT_decl_line : 30
<7812a81> DW_AT_decl_column : 38
<7812a82> DW_AT_type : <0x7812a88>
<7812a86> DW_AT_data_member_location: 32
struct alloc_tag {
struct codetag ct;
struct alloc_tag_counters __percpu *counters;
} __aligned(8);
Its the __percpu, something else to catch in the DWARF loader and then
to use when pretty printing.
⬢ [acme@toolbx linux]$ pahole -F dwarf -C alloc_tag ../build/v6.15.0-rc2+/vmlinux
struct alloc_tag {
struct codetag ct __attribute__((__aligned__(8))); /* 0 32 */
struct alloc_tag_counters * counters; /* 32 8 */
/* size: 40, cachelines: 1, members: 2 */
/* forced alignments: 1 */
/* last cacheline: 40 bytes */
} __attribute__((__aligned__(8)));
⬢ [acme@toolbx linux]$
- Arnaldo
> Looks like broken DWARF, there should be just one DW_AT_name per
> DW_TAG_base_type, what is the language for the CU where the bad cases
> appear? Is some sort of LTO being used?
