.eh_frame augmentation character for MTE stack tagging

.eh_frame augmentation character for MTE stack tagging

[Florian Mayer]

Hey!

We are in the process of implementing MTE (Memory Tagging Extension)
stack tagging in LLVM. To support stack tagging in combination with
exceptions, we need to make sure that the unwinder will untag stack
frames, to avoid leaving behind stale tags. As such, we need some way
to communicate to the unwinder to do that.

In a discussion on llvm-dev [1], it was decided the best way to go
forward with this would be to add a new character ('G' for taG, as the
MTE instructions stg etc.) to the eh_frame augmentation string, and
then handle that in libunwind by clearing the tags of the respective
frame.

How does that sound? Would that be a good course of action for GCC as well?

Thanks,
Florian

[1]: https://lists.llvm.org/pipermail/llvm-dev/2020-May/141345.html

Re: .eh_frame augmentation character for MTE stack tagging

[Richard Earnshaw]

On 04/06/2022 00:52, Florian Mayer via Gcc wrote:
> Hey!
> 
> We are in the process of implementing MTE (Memory Tagging Extension)
> stack tagging in LLVM. To support stack tagging in combination with
> exceptions, we need to make sure that the unwinder will untag stack
> frames, to avoid leaving behind stale tags. As such, we need some way
> to communicate to the unwinder to do that.
> 
> In a discussion on llvm-dev [1], it was decided the best way to go
> forward with this would be to add a new character ('G' for taG, as the
> MTE instructions stg etc.) to the eh_frame augmentation string, and
> then handle that in libunwind by clearing the tags of the respective
> frame.
> 
> How does that sound? Would that be a good course of action for GCC as well?
> 
> Thanks,
> Florian
> 
> [1]: https://lists.llvm.org/pipermail/llvm-dev/2020-May/141345.html

Hi Florian,

This is something that needs to be specified in the ABI, not just agreed 
between a couple of compilers. So while the community input is helpful, 
it isn't enough.

The correct place to do this is in the ABI project here: 
https://github.com/ARM-software/abi-aa

R.

Re: .eh_frame augmentation character for MTE stack tagging

[Matthew Malcomson]

Hi there,

Just to mention that this decision has been included in the Arm ABI project.

https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst#id22

MM

On 6/6/22 12:00, Richard Earnshaw via Gcc wrote:
> 
> 
> On 04/06/2022 00:52, Florian Mayer via Gcc wrote:
>> Hey!
>>
>> We are in the process of implementing MTE (Memory Tagging Extension)
>> stack tagging in LLVM. To support stack tagging in combination with
>> exceptions, we need to make sure that the unwinder will untag stack
>> frames, to avoid leaving behind stale tags. As such, we need some way
>> to communicate to the unwinder to do that.
>>
>> In a discussion on llvm-dev [1], it was decided the best way to go
>> forward with this would be to add a new character ('G' for taG, as the
>> MTE instructions stg etc.) to the eh_frame augmentation string, and
>> then handle that in libunwind by clearing the tags of the respective
>> frame.
>>
>> How does that sound? Would that be a good course of action for GCC as 
>> well?
>>
>> Thanks,
>> Florian
>>
>> [1]: https://lists.llvm.org/pipermail/llvm-dev/2020-May/141345.html
> 
> Hi Florian,
> 
> This is something that needs to be specified in the ABI, not just agreed 
> between a couple of compilers. So while the community input is helpful, 
> it isn't enough.
> 
> The correct place to do this is in the ABI project here: 
> https://github.com/ARM-software/abi-aa
> 
> R.