Hi Ulrich,

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