[PATCH v5 19/25] arm64: mte: Add PTRACE_{PEEK,POKE}MTETAGS support

[Luis Machado]

Hi,

On 7/1/20 2:16 PM, Catalin Marinas wrote:
> Hi Luis,
> 
> On Thu, Jun 25, 2020 at 02:10:10PM -0300, Luis Machado wrote:
>> I have one point below I wanted to clarify regarding
>> PEEKMTETAGS/POKEMTETAGS.
>>
>> But before that, I've pushed v2 of the MTE series for GDB here:
>>
>> https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/luisgpm/aarch64-mte-v2
>>
>> That series adds sctlr and gcr registers to the NT_ARM_MTE (still using a
>> dummy value of 0x407) register set. It would be nice if the Linux Kernel and
>> the debuggers were in sync in terms of supporting this new register set. GDB
>> assumes the register set exists if HWCAP2_MTE is there.
>>
>> So, if we want to adjust the register set, we should probably consider doing
>> that now. That prevents the situation where debuggers would need to do
>> another check to confirm NT_ARM_MTE is exported. I'd rather avoid that.
> 
> I'm happy to do this before merging, though we need to agree on the
> semantics.
> 
> Do you need both read and write access? Also wondering whether the

If I recall the previous discussion correctly, Kevin thought access to 
both of these would be interesting to the user. It sounded like having 
read-only access was enough. If so,...

> prctl() value would be a better option than the raw register bits (well,
> not entirely raw, masking out the irrelevant part).

... then exposing the most useful bits to the user would be better, and 
up to you to define.

I can tweak the GDB patches to turn the sctlr and gcr values into flag 
fields. Then GDB can just show those in a more meaningful way. I just 
need to know what the bits would look like.

I'd rather not make these values writable if we don't think there is a 
good use case for it. Better avoid giving developers more knobs than 
they need?