Re: [DTrace-devel] [PATCH] sparc: remove architecture support

[Nick Alcock <nick.alcock@oracle.com>]

I'm leaving most of this patch to Eugene, but...

On 4 Mar 2026, Eugene Loh via DTrace-devel spake thusly:

>> index 23454d63..6a0e0122 100644
>> --- a/libdtrace/procfs.d.in
>> +++ b/libdtrace/procfs.d.in
>> @@ -286,8 +286,7 @@ define_for_kernel([[on_cpu]], [[(m4_kver(5,16,0), m4_dnl
>>     [[((struct thread_info *)T->stack)->cpu]]), m4_dnl
>>   (m4_kver(4,9,0), m4_dnl
>>     [[if_arch([[x86]],[[T->cpu]])]] m4_dnl
>> -  [[if_arch([[arm64]],[[T->cpu]])]] m4_dnl
>> -  [[if_arch([[sparc]],[[((struct thread_info *)T->stack)->cpu]])]])]], m4_dnl
>> +  [[if_arch([[arm64]],[[T->cpu]])]]l)]], m4_dnl
>>   [[((struct thread_info *)T->stack)->cpu]])m4_dnl
>>   	pr_onpro = on_cpu;
>>   };
>
> I can't read M4, but maybe that diff is suspicious?  This is what gpt 5.2 says:

*counts painfully*

I think this is fine, modulo the stray 'l' (correctly pointed out by GPT
5.2). The apparently unbalanced closing )]] is closing the "(m4_kver"
and opening "[[if_arch(..." from a few lines earlier: the removed sparc
line above it had the same trailers.

> ### ASSISTANT
> No — as shown, that diff does **not** make sense, and the brackets/parentheses are very likely **not balanced** anymore (and

Wrong.

> ### What looks wrong
>
> 1. **Stray `l` and unmatched delimiters**
>    ```
>    [[if_arch([[arm64]],[[T->cpu]])]]l)]], m4_dnl
>                               ^^^
>    ```
>    That `l)` sequence is almost certainly accidental. It also strongly suggests you now have an extra `)` and/or `]` compared to
> what was intended.

Wrong.

> 2. **You removed the `sparc` branch and spliced the “default” expression oddly**
>    Originally you had:
>    ```
>    ... [[if_arch([[arm64]],[[T->cpu]])]] m4_dnl
>        [[if_arch([[sparc]],[[((struct thread_info *)T->stack)->cpu]])]])]], m4_dnl
>    ```
>    That last line clearly closes a number of nested `[[ ... ]]` / `(...)` constructs.
>
>    In the new version, you have:
>    ```
>    [[if_arch([[arm64]],[[T->cpu]])]]l)]], m4_dnl
>    [[((struct thread_info *)T->stack)->cpu]])m4_dnl
>    ```
>    The “default” `[[((struct thread_info *)T->stack)->cpu]]` expression now appears outside of the previous nesting, and the
> closers that used to be on the `sparc` line are now partially (and incorrectly) attached to the `arm64` line.

Well, yes, you do have to close the same number of closers in total, not
just the same number that were opened on *that line* :)

> 3. **`m4_dnl` placement**
>    `m4_dnl` comments out the rest of the line. Moving delimiters to a new line while also changing where `m4_dnl` lands can easily
> break balanced delimiters, because closers might end up being “commented away” or no longer part of the intended argument.

Err... the patch didn't do that.

> ### Practical conclusion
> - **Brackets are almost certainly unbalanced** after this edit.

Wrong :)

-- 
NULL && (void)