Re: [PATCH v2] MIPS: Fix MAX_REG_OFFSET and remove zero-length struct member

[Thorsten Blum <thorsten.blum@linux.dev>]

On 18. Apr 2025, at 17:14, Maciej W. Rozycki wrote:
> On Fri, 18 Apr 2025, Thorsten Blum wrote:
>>>> Does regs_get_register() even work for CPU_CAVIUM_OCTEON when accessing
>>>> the last two registers because they're both ULL, not UL? (independent of
>>>> my patch)
>>> 
>>> Or rather two arrays of registers.  With 32-bit configurations their 
>>> contents have to be retrieved by pieces.  I don't know if it's handled by 
>>> the caller(s) though as I'm not familiar with this interface.
>> 
>> Ah, CPU_CAVIUM_OCTEON seems to be 64-bit only, so there's no difference
>> between UL and ULL. Then both my patch and your suggestion:
> 
> So it seems odd to use `long long int' here, but I can't be bothered to 
> check history.  There could be a valid reason or it could be just sloppy 
> coding.
> 
>> I still prefer my approach without '__last[0]' because it also silences
>> the following false-positive Coccinelle warning, which is how I stumbled
>> upon this in the first place:
>> 
>>  ./ptrace.h:51:15-21: WARNING use flexible-array member instead
> 
> So make `__last' a flexible array instead?  With a separate patch.

No, '__last[0]' is a fake flexible array and the Coccinelle warning is
wrong. We should either ignore the warning or silence it by removing the
marker, but turning it into a real flexible array doesn't make sense.
I'd prefer to just remove it from the struct.

Stefan or Oleg, do you have any preference?

> Would it make sense to also change the register arrays 'mpl' and 'mtp'
>> from ULL to UL? ULL seems unnecessarily confusing to me.
> 
> Maybe, but I'm not familiar enough with the Cavium Octeon platform to 
> decide offhand and I won't dive into it, sorry.

Everything I've found about Cavium Octeon indicates it's 64-bit only, so
whether we use UL or ULL doesn't matter - they're both 64-bit values.

Thorsten