Hi,

>> +DEFHOOK
>> +(compose_offset_tag,
>> + "Return an RTX that represnts the result of composing @var{tag_offset} 
>> with\n\
>> +the base tag @var{base_tag}.\n\
>> +The default of this hook is to byte add @var{tag_offset} to 
>> @var{base_tag}.",
>> +  rtx, (rtx base_tag, uint8_t tag_offset), 
>> default_memtag_compose_offset_tag)
>> +
> 
> I can't remember whether this was the result of a previous discussion,
> sorry, but I'm not sure about the interface.  It seems that "base_tag"
> really is a tag for the hwasan case, but is actually a tagged address
> for MTE.  It therefore feels like these are two separate operations.

This was not in the previous discussions. My problem was that in asan.c
the tag operations are done on the extracted tag, while in the case of
MTE, we can operated directly on the address-tag tuple using addg/subg
instructions. Thus, I've introduced this hook which in the case of MTE
will use addg/subg instructions when we want to add the tag, otherwise,
a simple add of the input tag and offset is used. The purpose here is to
avoid extraction/insertion of the tag as much as possible as well as
changing the asan code only when it is really needed.

> 
> Since there is no immediate need to put the current hwasan behaviour
> behind a hook, how about defining an interface specifically for memtag
> sanitisation that explicitly has a tagged base address as its first
> operand?

I'll look into it.
To be clear for me, shall I remove this hook from asan for time being?

> 
> The memtag behaviour feels more like an optab than a hook to me, but I
> realise that the other sanitiser stuff is heavily hook-based, so I won't
> try to push for an optab here.
> 

I've was thinking about an optab but it was bringing too many
modifications, leading to much more complex patch. In this particular
case, the design requires to not return an instruction. However, there
are other hooks which can be converted to optabs, but that will impact
x86 port. I can make a patch to change hooks to optabs, but I would
prefer to be separate one.

Thank you,
Claudiu



Reply via email to