Re: [PATCH v3 21/24] Extend "x" and "print" commands to support memory tagging

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2020-12-29 1:50 p.m., Luis Machado wrote:
> The switch that controls this is the one that enables/disables memory tagging. It controls both the print command behavior and the "x" command behavior.
> 
> Do you think we should have a command for each individual command?

Hmm well I'm comparing it to the other "set print" options.  If you
add an option (say, "memory-tag-violations" to the
value_print_option_defs array, you get both

  set print memory-tag-violations on/off

and

  print -memory-tag-violations on/off

options for free.

And now that I think about it a bit more, I am not sure why the
"set memory-tagging" exists (at least as of today).  It controls
whether you can use the "memory-tag" commands, but I don't really
see why that's useful.  If you don't want to use these commands,
you can just not use them not need for them to be disabled.

Otherwise, the memory_tagging global is only used to control
whether "print" and "x" should talk about memory tags.  With
my suggestion above, print already has its -memory-tag-violations
flag and "set print memory-tag-violations" option.  And the
"x" command already has its /m option that you implemented.
So I don't see a need for the "set memory-tagging" option.

If tracking memory tags required maintaining a state as the
program runs, then it would make sense to have a
"set memory-tagging on/off" option to enable/disable that
feature.

And I think that printing memory tags and printing memory tag
violations are two separate things, so we should be precise in
the option names.  We might later want to implement a "print"
option to print the logical tags every time a pointer value is
printed (a bit like symbols are printed when the pointer points
to a symbol).  That could then be controlled by

  set print memory-logical-tags
  print -memory-logical-tags

By naming the new print option "memory-tag-violations" (rather
than say "memory-tags"), we leave the door open to things like
that.

Random usage questions:

If I do

  (gdb) print myptr

and myptr has the wrong logical tag for the pointed memory area,
it will print that there is a memory tag violation.  But will it
also print it if myptr is dereferenced in an expression, like
this?

  (gdb) print *myptr + 2

I guess not, as this is only checked when the final value is
printed.  Is this something we might want in the future?

What happens for arrays?  If the granule size is 16 bytes, but you
have an array of 32 bytes, does the array have two different
allocation tags?  But then the pointer (that points to the beginning
of the array) can only contain a single logical tag.  What happens
when you use the pointer to access the various areas of the array?

Simon