Re: [PATCH 1/3] dwarf_loader: Initial support for DW_TAG_variant_part

On Wed, Apr 08, 2026 at 02:36:17PM -0300, Arnaldo Carvalho de Melo wrote:
> On Wed, Apr 08, 2026 at 03:05:35PM +0100, Alan Maguire wrote:
> > On 23/03/2026 21:15, Arnaldo Carvalho de Melo wrote:
> > > +void type__add_variant_part(struct type *type, struct variant_part *vpart);
 
> > >  struct class_member *
> > >  	type__find_first_biggest_size_base_type_member(struct type *type,
  
> > do we also need some cleanup for the variant parts in type__delete() something like:
> > 
> > 	list_for_each_entry_safe(pos, n, type->variant_parts, node) {
> > 		list_del_int(&pos->node);
> > 		free(pos);
> > 	}
 
> Right, I'll fix it in v2, there are some other issues that Claude
> detected that I'll address in the enumeration case, one of them can be
> seen here:

Done with:

static void type__delete_variant_parts(struct type *type, struct cu *cu)
{
        struct variant_part *pos, *next;

        type__for_each_variant_part_safe_reverse(type, pos, next) {
                list_del_init(&pos->tag.node);
                variant_part__delete(pos, cu);
        }
}

Called from type__delete(), as you suggested.
 
> ⬢ [acme@toolbx pahole]$ pahole -C ProgramKind /tmp/build/perf-tools-next/tests/workloads/code_with_type.a
> enum ProgramKind {
> 	PathLookup = 0,
> 	Relative   = 1,
> 	Absolute   = 2,
> 	�3"��     = 140698500347136,
> } __attribute__((__packed__));
> 
> ⬢ [acme@toolbx pahole]$
> 
> Namely this Rust enum has a DW_TAG_subprogram, that
> enumeration__fprintf() doesn't know about, fixing it now.

Finally got back to working on this:

⬢ [acme@toolbx pahole]$ pahole -C ProgramKind /tmp/build/perf-tools-next/tests/workloads/code_with_type.a
enum ProgramKind {
	PathLookup = 0,
	Relative   = 1,
	Absolute   = 2,
	enum ProgramKind new(struct &std::ffi::os_str::OsStr),
} __attribute__((__packed__));

⬢ [acme@toolbx pahole]$

Will submit a v2 series,

- Arnaldo