Skip to contentSkip to conversation

Sashiko reviews for pahole: missing custom_remotes

PATCH Arnaldo Carvalho de Melo 2 participants 4 messages Jun 19 – Jun 22

lore
Share & tools
lore
#0 lore raw

Hi Roman,

The [email protected] mailing list is being tracked:

https://sashiko.dev/#/?list=org.kernel.vger.dwarves

But all the patches for pahole are failing to apply, I think we
need to have the second hunk applied, the first should be there as it is being tracked, can you please take a look and fix this?

Thanks,

- Arnaldo

Settings.toml +7 -1
index 61978b51f89a0d86..666b4e8f1b7a76f3 100644
@@ -5,7 +5,7 @@ url = "sashiko.db"
 token = ""
 
 [mailing_lists]
-track = ["linux-kernel"]
+track = ["linux-kernel", "dwarves"]
 
 [nntp]
 server = "nntp.lore.kernel.org"
@@ -104,6 +104,12 @@ port = 8080
 repository_path = "third_party/linux"
 
 # Track custom remotes and attempt to apply patches on their branches
+[[git.custom_remotes]]
+name = "pahole"
+url = "git://git.kernel.org/pub/scm/devel/pahole/pahole.git"
+check_all_branches = false
+only_branches = ["next", "master"]
+
 # [[git.custom_remotes]]
 # name = "remote-name"
 # url = "git://my-custom.com/remote"
#1 lore raw

Hi Arnaldo,

Sashiko is not really officially supporting a non-kernel code yet. It might work occasionally, but I can’t guarantee anything and results might be pathetic.
We might explore adding support for more project going forward, but we’re not there yet.

Thanks

Quoted 42 lines · Arnaldo Carvalho de Melo

Hi Roman,

The [email protected] mailing list is being tracked:

https://sashiko.dev/#/?list=org.kernel.vger.dwarves

But all the patches for pahole are failing to apply, I think we
need to have the second hunk applied, the first should be there as it is being tracked, can you please take a look and fix this?

Thanks,

- Arnaldo

Settings.toml +0 -0
index 61978b51f89a0d86..666b4e8f1b7a76f3 100644
@@ -5,7 +5,7 @@ url = "sashiko.db"

token = ""

[mailing_lists]

Settings.toml +1 -1
-track = ["linux-kernel"]
+track = ["linux-kernel", "dwarves"]

[nntp]
server = "nntp.lore.kernel.org"

Settings.toml +0 -0
@@ -104,6 +104,12 @@ port = 8080

repository_path = "third_party/linux"

# Track custom remotes and attempt to apply patches on their branches +[[git.custom_remotes]]

Settings.toml +5 -0
+name = "pahole"
+url = "git://git.kernel.org/pub/scm/devel/pahole/pahole.git"
+check_all_branches = false
+only_branches = ["next", "master"]
+

# [[git.custom_remotes]]

# name = "remote-name"
# url = "git://my-custom.com/remote"
#2 lore raw
Quoted 4 lines · Roman Gushchin

Hi Arnaldo,

Sashiko is not really officially supporting a non-kernel code yet. It might work occasionally, but I can’t guarantee anything and results might be pathetic.

I'm using it locally with great results, using:

acme@number:~/git/sashiko$ cat Settings.toml | grep -B1 -A3 'dwarves\|pahole'
[mailing_lists]
track = ["linux-kernel", "dwarves"]

[nntp]
server = "nntp.lore.kernel.org"
--
[[git.custom_remotes]]
name = "pahole"
url = "git://git.kernel.org/pub/scm/devel/pahole/pahole.git" check_all_branches = false
only_branches = ["next", "master"]

acme@number:~/git/sashiko$

Submitting series to sashiko with:

$ sashiko-cli submit FIRST_SHA^..LAST_SHA --repo /home/acme/git/pahole

With great results, for instance:

acme@number:~$ sashiko-cli show 132 | head -100
Patchset Details:
  ID:        132
  Subject:   dwarf_loader: Initial support for DW_TAG_variant_part
  Author:    Arnaldo Carvalho de Melo <[email protected]>
  Status:    Failed
  Date:      2026-06-20 11:23:54

Patches (16):
[1] dwarf_loader: Initial support for DW_TAG_variant_part (Reviewed) [Issues Found] {cache: 1322/2592 hits, 16.5M tokens saved}
[2] dwarf_loader: Allow forcing the merge of CUs for solving inter CU tag references (Reviewed) [Reviewed] {cache: 1321/2567 hits, 16.5M tokens saved}
[3] dwarf_loader: Initial support for DW_TAG_subprogram in DW_TAG_enumeration (Reviewed) [Issues Found] {cache: 1324/2542 hits, 16.5M tokens saved}
[4] encoders: Fix diagnostic messages for unexpected tags in enumerations (Reviewed) [Reviewed] {cache: 818/1833 hits, 10.0M tokens saved}
[5] dwarves_fprintf: Accumulate function__fprintf return value in enumeration printing (Failed) [Failed] {cache: 309/401 hits, 3.8M tokens saved}
[6] dwarves: Use tag__delete for enumeration children (Reviewed) [Reviewed] {cache: 1325/2534 hits, 16.5M tokens saved}
[7] btf_encoder: Fix types__match parameter comparison in BTF_KIND_FUNC_PROTO (Reviewed) [Reviewed] {cache: 508/1429 hits, 6.1M tokens saved}
[8] encoders: Handle DW_TAG_subprogram in enumerations during BTF/CTF encoding (Reviewed) [Reviewed] {cache: 64/624 hits, 719.8k tokens saved}
[9] dwarf_loader: Populate DW_TAG_variant children in DW_TAG_variant_part (Reviewed) [Issues Found] {cache: 1325/2570 hits, 16.5M tokens saved}
[10] btf_encoder: Encode variant parts as union members in BTF (Reviewed) [Reviewed] {cache: 965/2027 hits, 11.9M tokens saved}
[11] dwarf_loader: Handle DW_FORM_block in attr_numeric for Rust discriminant values (Reviewed) [Issues Found] {cache: 1325/2614 hits, 16.5M tokens saved}
[12] dwarf_loader: Support DW_TAG_imported_unit for same-file partial units (Reviewed) [Issues Found] {cache: 1320/2550 hits, 16.5M tokens saved}
[13] dwarf_loader: Fix cus__merging_cu failing to detect DW_FORM_ref_addr (Reviewed) [Reviewed] {cache: 274/1071 hits, 3.2M tokens saved}
[14] tests: Add inter-CU type reference comparison test (Reviewed) [Reviewed] {cache: 280/1097 hits, 3.2M tokens saved}
[15] tests: Guard cleanup() against empty outdir to prevent rm /* (Reviewed) [Reviewed] {cache: 1233/2356 hits, 15.5M tokens saved}
[16] tests: Source test_lib.sh via dirname so tests run from any directory (Failed) [Failed] {cache: 322/405 hits, 4.2M tokens saved}

Cache: 14035/29212 hits (48.0%), 174.2M tokens saved, 530.8M tokens stored

Review Summary:
Model: gemini-3.1-pro-preview

Patch 1: dwarf_loader: Initial support for DW_TAG_variant_part
Critical: 0 · High: 0 · Medium: 0 · Low: 1

[Low]

commit 3d23ae0089bbe7cda5b12c12f58ad92e02812f2b
Author: Arnaldo Carvalho de Melo <[email protected]>
Subject: dwarf_loader: Initial support for DW_TAG_variant_part

This commit adds initial scaffolding for parsing DW_TAG_variant_part entries from Rust DWARF. The goal is to allow perf to process Rust workloads and test pahole's pretty printing features.

Quoted 13 lines
dwarf_loader.c +2 -0
index 8ce34cbb8ed60aca..438ebd52893fdb8f 100644
@@ -508,6 +508,8 @@ static void tag__init(struct tag *tag, struct cu *cu, Dwarf_Die *die)
 
 	if (tag->tag == DW_TAG_imported_module || tag->tag == DW_TAG_imported_declaration)
 		dwarf_tag__set_attr_type(dtag, type, die, DW_AT_import);
+	else if (tag->tag == DW_TAG_variant_part)
+		dwarf_tag__set_attr_type(dtag, type, die, DW_AT_discr);
 	else
 		dwarf_tag__set_attr_type(dtag, type, die, DW_AT_type);
 

[ ... ]

Quoted 6 lines
dwarf_loader.c +0 -1
@@ -2085,9 +2099,19 @@ static int die__process_class(Dwarf_Die *die, struct type *class,
 		case DW_TAG_GNU_template_template_param:
 #endif
 		case DW_TAG_subrange_type: // XXX: ADA stuff, its a type tho, will have other entries referencing it...
-		case DW_TAG_variant_part: // XXX: Rust stuff
 			tag__print_not_supported(die);

dwarf_loader.c static int die__process_class(Dwarf_Die *die, struct type *class, · line 2112

Quoted 10 lines
dwarf_loader.c +9 -0
 			continue;
+		case DW_TAG_variant_part: {
+			struct variant_part *vpart = variant_part__new(die, cu, conf);
+
+			if (vpart == NULL)
+				return -ENOMEM;
+
+			// For rust it seems we have just one, but DWARF, according to Gemini, support having
+			// more than one DW_TAG_variant_part for a given DW_TAG_structure_type, so future proof it
+			type__add_variant_part(class, vpart);

[Severity: Low]
Are we missing a call to cu__table_add_tag() here before adding the variant part?

Since variant_part tags are not added to the CU's tags table, they will be skipped entirely during type recoding in cu__recode_dwarf_types(). This leaves the DW_AT_discr attribute extracted earlier in tag__init() as a raw DIE offset rather than a valid small_id, which makes the extracted discriminant unusable.

dwarf_loader.c static int die__process_class(Dwarf_Die *die, struct type *class, · line 2115

Quoted 3 lines
dwarf_loader.c +2 -0
+			continue;
+		}
 		case DW_TAG_template_type_parameter: {

Patch 2: dwarf_loader: Allow forcing the merge of CUs for solving inter CU tag references
Critical: 0 (2) · High: 0 · Medium: 0 · Low: 0

[Critical]
[Critical]

commit 72c660e79f1db109e3466377d4d7f2ea187787f4
Author: Arnaldo Carvalho de Melo <[email protected]>

dwarf_loader: Allow forcing the merge of CUs for solving inter CU tag references

thread 'main' (127686) panicked at library/std/src/io/stdio.rs:1165:9:
failed printing to stdout: Broken pipe (os error 32)
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace acme@number:~

Etc.

Quoted 1 line

We might explore adding support for more project going forward, but we’re not there yet.

Your call, but just as a data point, its being useful for me for pahole development and I bet other pahole developers would like having it enabled, since it seems to be useful with the current sashiko codebase.

- Arnaldo

Quoted 44 lines

Thanks

Quoted 42 lines · Arnaldo Carvalho de Melo

Hi Roman,

The [email protected] mailing list is being tracked:

https://sashiko.dev/#/?list=org.kernel.vger.dwarves

But all the patches for pahole are failing to apply, I think we
need to have the second hunk applied, the first should be there as it is being tracked, can you please take a look and fix this?

Thanks,

- Arnaldo

Settings.toml +0 -0
index 61978b51f89a0d86..666b4e8f1b7a76f3 100644
@@ -5,7 +5,7 @@ url = "sashiko.db"

token = ""

[mailing_lists]

Settings.toml +1 -1
-track = ["linux-kernel"]
+track = ["linux-kernel", "dwarves"]

[nntp]
server = "nntp.lore.kernel.org"

Settings.toml +0 -0
@@ -104,6 +104,12 @@ port = 8080

repository_path = "third_party/linux"

# Track custom remotes and attempt to apply patches on their branches +[[git.custom_remotes]]

Settings.toml +5 -0
+name = "pahole"
+url = "git://git.kernel.org/pub/scm/devel/pahole/pahole.git"
+check_all_branches = false
+only_branches = ["next", "master"]
+

# [[git.custom_remotes]]

# name = "remote-name"
# url = "git://my-custom.com/remote"
#3 lore raw
Quoted 25 lines · Arnaldo Carvalho de Melo
Quoted 2 lines · Roman Gushchin

Sashiko is not really officially supporting a non-kernel code yet. It might work occasionally, but I can’t guarantee anything and results might be pathetic.

I'm using it locally with great results, using:

acme@number:~/git/sashiko$ cat Settings.toml | grep -B1 -A3 'dwarves\|pahole'
[mailing_lists]
track = ["linux-kernel", "dwarves"]

[nntp]
server = "nntp.lore.kernel.org"
--
[[git.custom_remotes]]
name = "pahole"
url = "git://git.kernel.org/pub/scm/devel/pahole/pahole.git" check_all_branches = false
only_branches = ["next", "master"]

acme@number:~/git/sashiko$

Submitting series to sashiko with:

$ sashiko-cli submit FIRST_SHA^..LAST_SHA --repo /home/acme/git/pahole
Quoted 7 lines

With great results, for instance:

Quoted 1 line

We might explore adding support for more project going forward, but we’re not there yet.

Your call, but just as a data point, its being useful for me for pahole development and I bet other pahole developers would like having it enabled, since it seems to be useful with the current sashiko codebase.

This series:

https://lore.kernel.org/all/[email protected]/

For instance, has several bugs addressed from review comments by Sashiko, that is credited:

commit bf5e28c65bc52e61361a676acc9d2913b6d9e065

Author: Arnaldo Carvalho de Melo <[email protected]>
Date:   Fri Jun 19 11:34:02 2026 -0300

tests: Guard cleanup() against empty outdir to prevent rm /*

If make_tmpdir() fails, outdir is empty. The cleanup() function executes rm ${outdir}/* which expands to rm /* when outdir is unset or empty — potentially deleting the entire root filesystem.

Add a guard to check that outdir is non-empty and points to an existing directory before attempting removal.

Fixes 52dbfb0b39595ed8 ("pahole: Refactor selftests")
Reported-by Sashiko:gemini-3-1-pro-preview # Running on a local machine
Assisted-by Claude:claude-opus-4-6

Cheers,

- Arnald