On 2024-02-06 11:23:54 [-0300], Arnaldo Carvalho de Melo wrote:
> > > compiling and running pahole afterwards:
> > > | make kernel/pahole-tc.o && pahole -J --btf_gen_floats -j --lang_exclude=rust kernel/pahole-tc.o
> > > | CC kernel/pahole-tc.o
> > > | error: found variable 'per_cpu_struct' in CU 'kernel/pahole-tc.c' that has void type
> > >
> > > This doesn't look good. If I swap the order of "lock" and "something"
> > > within per_cpu_struct then it goes away.
> > > The dwarf/die object it complains about has only DW_AT_abstract_origin
> > > and DW_AT_location set.
>
> Are you sure?
I added to variable__new():
| for (i = 0; i < DW_AT_hi_user; i++) {
| if (dwarf_hasattr(die, i))
| fprintf(stderr, " => ATTR %x\n", i);
| }
and I get:
| => ATTR 2
| => ATTR 31
so this what I have to say in my defence ;)
> What I see:
>
> ⬢[acme@toolbox pahole]$ cp sebastian-rt-void-variable-btf/pahole-tc/pahole-tc-bad.o .
> ⬢[acme@toolbox pahole]$ pahole --btf_encode pahole-tc-bad.o
> error: found variable 'per_cpu_struct' in CU 'kernel/pahole-tc.c' that has void type
> ⬢[acme@toolbox pahole]$
>
> ⬢[acme@toolbox pahole]$ readelf -wi sebastian-rt-void-variable-btf/pahole-tc/pahole-tc-bad.o | grep DW_TAG_variable -A5 | grep -w per_cpu_struct -B1 -A4
> <1><764>: Abbrev Number: 29 (DW_TAG_variable)
> <765> DW_AT_name : (indirect string, offset: 0x184): per_cpu_struct
> <769> DW_AT_decl_file : 1
> <769> DW_AT_decl_line : 9
> <76a> DW_AT_decl_column : 8
> <76b> DW_AT_type : <0x73c>
> ⬢[acme@toolbox pahole]$
>
> ⬢[acme@toolbox pahole]$ readelf -wi sebastian-rt-void-variable-btf/pahole-tc/pahole-tc-bad.o | grep '<73c>.*DW_TAG_structure_type' -A7
> <1><73c>: Abbrev Number: 4 (DW_TAG_structure_type)
> <73d> DW_AT_name : (indirect string, offset: 0x184): per_cpu_struct
> <741> DW_AT_byte_size : 136
> <742> DW_AT_decl_file : 1
> <743> DW_AT_decl_line : 4
> <744> DW_AT_decl_column : 8
> <745> DW_AT_sibling : <0x764>
> <2><749>: Abbrev Number: 1 (DW_TAG_member)
> ⬢[acme@toolbox pahole]$
>
> But when using verbose mode:
>
> [95] FUNC function type_id=94
> search cu 'kernel/pahole-tc.c' for percpu global variables.
> Variable 'per_cpu_struct' from CU 'kernel/pahole-tc.c' at address 0x0 encoded
> [96] VAR per_cpu_struct type=90 linkage=0
> Variable 'per_cpu_struct' from CU 'kernel/pahole-tc.c' at address 0x0 encoded
> [97] VAR per_cpu_struct type=91 linkage=0
> error: found variable 'per_cpu_struct' in CU 'kernel/pahole-tc.c' that has void type
> [98] DATASEC .data..percpu size=136 vlen=2
> type=96 offset=0 size=136
> type=97 offset=0 size=136
> ⬢[acme@toolbox pahole]$ pahole -V --btf_encode pahole-tc-bad.o
>
> It ends up considering two variables with that name?
Yes. That is the odd part. The second one comes from the guard()
construct which has also a this_cpu_ptr() as part of local_lock(). After
a while I figured out that dwarf_tag->id is the same as in dwarfdump
output and this matched the "t".
> ⬢[acme@toolbox pahole]$ readelf -wi sebastian-rt-void-variable-btf/pahole-tc/pahole-tc-bad.o | grep per_cpu_struct -B1 -A5
> <1><73c>: Abbrev Number: 4 (DW_TAG_structure_type)
> <73d> DW_AT_name : (indirect string, offset: 0x184): per_cpu_struct
> <741> DW_AT_byte_size : 136
> <742> DW_AT_decl_file : 1
> <743> DW_AT_decl_line : 4
> <744> DW_AT_decl_column : 8
> <745> DW_AT_sibling : <0x764>
> --
> <1><764>: Abbrev Number: 29 (DW_TAG_variable)
> <765> DW_AT_name : (indirect string, offset: 0x184): per_cpu_struct
> <769> DW_AT_decl_file : 1
> <769> DW_AT_decl_line : 9
> <76a> DW_AT_decl_column : 8
> <76b> DW_AT_type : <0x73c>
> <76f> DW_AT_location : 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
> ⬢[acme@toolbox pahole]$
>
> Just dumping some more info in case Jiri or Alan thinks about something.
Thank you for looking at this Arnaldo.
> - Arnaldo
Sebastian
