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?
