Hi Ulrich,

On 28/09/26 14:52, Ulrich Weigand wrote:
> Abhay Kandpal<abhay@linux.ibm.com> wrote:
>   
>> The existing names encode the base ISA level, but DMR is a later ISA
>> feature layered on an isa207-derived description, so isa207-dmr would
>> misstate the ISA level. A few options:
>>
>> 1. powerpc-isa207-dmr-vsx64l - names the base feature set the description extends
>> 2. powerpc-isa32-dmr-vsx64l - names DMR's own ISA level (ISA 3.2)
>> 3. powerpc-dmr-vsx64l - as posted, no ISA level
> I'm not familiar with ISA 3.2 - is DMR mandatory or optional in 3.2?

I checked with our architecture team. DMR can't be disabled independently,
it depends on VSX being enabled, and an ISA 3.2 implementation running with
VSX disabled isn't a configuration that's supported in practice. So there is
no realistic ISA 3.2 target without DMR.

> And are there any *other* 3.2 features that GDB needs to implement?

No - DMR is the only new architected register state in ISA 3.2,
so the GDB work is limited to these registers.

>
> I'd prefer "powerpc-isa32-vsx64l" to refer to an implementation of
> all mandatory features (including DMR if mandatory), and if DMR is
> optional, then in addition "powerpc-isa32-dmr-vsx64l" for the
> combination of mandatory ISA 3.2 features plus DMR.

Given the above, v2 uses a single description,|powerpc-isa32-vsx32l/64l|,
which includes DMR. Your other comments are addressed in v2 as well.

Regards,
Abhay

>
>   
>> So in v2 I'll convert the native side to the regset mechanism
>> throughout: fetch_regset/store_regset with NT_PPC_DMR in
>> fetch_register, fetch_ppc_registers, store_register and
>> store_ppc_registers, and a regset-based availability check in
>> read_description. That removes the need for the
>> PTRACE_GETDMREGS/PTRACE_SETDMREGS defines, so I'll drop the
>> block rather than move it - unless something still needs them,
>> in which case I'll relocate it as you suggest.
> No, if they're not needed, it's better to drop these defines.
>
>> Yes - PPC_FEATURE2_DMF (0x00008000, Dense Math Facility). I'll add
> that
>> check. The kernel does save and restore these registers across context
>> switches. The hwcap bit and the DMR ptrace support are currently in
>> separate kernel branches here, so I'm assembling a tree with both before
>> validating v2.
> Thanks!
>
> Bye,
> Ulrich