Hi Luis, On Thu, Aug 13, 2020 at 11:01:06AM -0300, Luis Machado wrote: > There has been changes to GDB's/LLDB's side to incorporate a tag type into > the peek/poke requests. This is an attempt to anticipate required support > for other tag types, like CHERI's tags. Those are somewhat different from > MTE's tags. Please note that Morello (the ARM's CHERI implementation) won't go into mainline Linux for the time being. It's a development board to experiment with CHERI and the architecture may eventually turn out slightly different. Also note that the current Morello hardware doesn't support MTE. The tags are indeed different from the MTE ones, though both are just additional metadata associated with a set of bytes in memory. It happens that a tag in both cases corresponds to a 16-byte memory range. > The core file design for storing tags, which is in progress and currently in > my court, is also taking into account other types of tags. It makes sense for the core file. > Given the above, should we consider passing a type to the kernel ptrace > requests as well? > > Also, since the ptrace requests would have to handle different types of > tags, should we rename PEEKMTETAGS/POKEMTETAGS to PEEKTAGS/POKETAGS instead > and make those requests generic? I'm not sure how we could pass a type since ptrace() only takes a single argument for the request. We could use a different structure than iovec and encode a type in a field in the new structure but I'd rather keep the generic struct iovec. So basically the "MTE" part in PEEKMTETAGS is the type. Internally, the kernel implementation will probably translate the request into a common function call with a tag type but for the user-visible ptrace() interface, I don't see what benefits it would bring. If you have a better suggestion on how to encode the type, I'm open to discuss it. -- Catalin
