Re: .eh_frame augmentation character for MTE stack tagging
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
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.
Re: [RFC] Support for nonzero attribute
On Sun, Jun 05, 2022 at 20:09:04 +, Miika via Gcc wrote: > Based on Jakub's and Yair's comments I created a new attribute "inrange". > Inrage takes three arguments, pos min and max. > Pos being the argument position in the function, and min and max defines the > range of valid integer. Both min and max are inclusive and work with enums. > Warnings are enabled with the new flag: "-Winrange". Is this something that could be applied to variables or types (I've not much experience with GCC attribute internal mechanisms, so maybe not)? For example: ``` // This variable must be in range. int percentage __attribute__((inrange(0, 100))); // Any variable declared through this typedef must be in range. typedef int __attribute__((inrange(0, 100))) percentage_t; ``` --Ben
Re: GSoC: Getting started
On 02/06/2022 00:20, David Malcolm wrote: (2) find a list of system calls (e.g. those implemented on Linux), and see which ones relate to file descriptors e.g. acquiring them, using them, releasing them, and duplicating them. Look for patterns of usage that could be expressed using function attributes. Probably ignore "ioctl" for now. (3) probably talk to glibc's developers about this, since glibc provides headers that wrap system calls, which would want to use the attributes if we provide them There are a significant number of interfaces that use file descriptors, not just limited to syscall interfaces. Another area I can think of is stdio, i.e. FILE interfaces. There are interfaces (e.g. fdopen) that interact with file descriptors and they may require some special handling. (4) implement the attributes, so that the analyzer doesn't have hardcoded function names, and can instead rely on function attributes. GCC's attributes are implemented in gcc/c-family/c-attribs.cc; see the big c_common_attribute_table array, which associates the string names of the attrbutes with properties, including a handler callback. These either set flags of a decl, or the attribute itself is appended to a singly-linked list on that decl (for those things that don't directly relate to fields of a decl). I believe Siddhesh Poyarekar has been looking at attributes from the glibc side of things, so I'm CCing him in case he has input on this. I'm wondering if other people on this list have ideas for projects that make heavy use of syscalls/file-descriptors that would benefit from having this analyzer feature. Maybe systemd? Systemd AFAIK doesn't bypass glibc's syscall interfaces, so annotating glibc headers ought to be good start for a GSoC project. If this is done before time we can explore server software, e.g. sshd, httpd, etc. to see if there's scope for additional annotations there. I'll be happy to help on the glibc and interfaces front. Siddhesh
