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

Luis Machado
2020-07-01T17:32:53Z

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?