User Details
- User Since
- Jun 18 2014, 12:59 AM (414 w, 3 d)
Tue, May 24
Mon, May 23
See https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html, documentation for "mharden-sls": For AArch64, the options available on the command line are "retbr", "blr", "none" and "all".
I don't think the options necessarily have to be the same for x86.
But assuming I understand this patch correctly, it seems to me that with this patch -mharden-sls=all would mean fundamentally slightly different things for x86 vs arm and aarch64, which could be confusing to users.
IIUC this patch correctly, this patch implements the equivalent of aarch64/arm's -mharden-sls=retbr (i.e. add a straight-line-speculation mitigation for returns and indirect jumps, but not for indirect function calls).
Therefore, I wonder if it wouldn't be better to name this -mharden-sls=retbr for more consistency across architectures?
Or is the indirect function call case not relevant for x86 (sorry - I'm not up to speed on the details on the x86 side)?
Fri, May 20
Thu, May 19
updated guidance based on Aaron's feedback.
Use correct syntax to indicate we're adding a subsubsection, not a section, see https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#sections
Wed, May 18
Fri, May 13
Tue, May 3
Apr 28 2022
LGTM
Mar 24 2022
Feb 21 2022
Feb 17 2022
Feb 16 2022
Feb 13 2022
LGTM, thank you!
Feb 8 2022
Feb 7 2022
LGTM, thank you @voltur01 !
Jan 21 2022
Jan 13 2022
I'm afraid I don't know if it's possible to check anywhere in public documentation that the values 0xc0 and 0xac3 are correct.
I'm assuming you verified those are the correct.
The code looks good, apart from one place where clang-format suggests different indentation.
With that indentation adapted, this looks good to me.
Jan 12 2022
Jan 11 2022
LGTM, thank you!
Dec 20 2021
I think this would be useful to have, as writing fine-grained filter rules is not necessarily easy or even doable in some mail clients, such as gmail.
With that in mind, I wonder if this action (which if I understand correctly will add a comment mentioning "@issue-subscribers-label"), results in the corresponding notification email adding "issue-subscribes-label@noreply.github.com"? I hope it does as that probably would make it easier to write email filters.
Dec 16 2021
Dec 14 2021
Nov 19 2021
I just have 2 bike-sheddy comments on the documentation text.
My comments should not let you delay in getting this committed if they do not make sense to you.
Nov 16 2021
LGTM, thanks.
Nov 15 2021
LGTM - thanks for fixing this!
Nov 10 2021
Nov 8 2021
Nov 5 2021
Nov 3 2021
GNU binutils has a specific option to silence the warnings about deprecated IT blocks (-m{no-}warn-restrict-it), see https://sourceware.org/legacy-ml/binutils/2019-12/msg00093.html.
I haven't looked up if GNU tools have the equivalent of -no-deprecated-warn.
Oct 22 2021
Oct 15 2021
@MaskRay - gentle ping: I wonder if you have any further remarks after I updated the patch based on your earlier feedback?
Oct 14 2021
Oct 7 2021
run clang-format on the patch.
Updated test based on feedback from @MaskRay
Oct 5 2021
LGTM, thank you for fixing this!
Oct 4 2021
LGTM, thanks!
On a side note, it looks like llvm/test/CodeGen/ARM/speculation-hardening-sls.ll doesn't contain many of the check lines I would expect any more, after e497b12a69604b6d691312a30f6b86da4f18f7f8. Is that expected, or should I make a patch to undo that?
For speculation-hardening-sls.ll: the approach taken in the ARM backend version of the similar test is probably a lot more robust, and I'd guess that if the test was adapted to follow the approach there ( see https://github.com/llvm/llvm-project/blob/566690b067c8175314fa657b899c99bccf96821c/llvm/test/CodeGen/ARM/speculation-hardening-sls.ll#L343), the compiler would still use the x16 register.
Sep 3 2021
I'm afraid that I'm not fully up to speed on the code changes here.
That being said, I hope it's useful to point out that I expect that in the not-too-distant future the recent specification of r11 being the frame pointer for both Arm and Thumb to be implemented in LLVM. See https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst (search for "frame pointer") to see the specification. A frame pointer was only recently added to the ABI specification. Before there was no definition of frame pointer for 32-bit ARM in the ABI specification.
Aug 30 2021
Aug 25 2021
The performance deprecation of certain forms of IT blocks has been reverted.
The performance deprecation notes are being removed from the Arm ARM.
I am expecting that in the near future, code generation for Arm will be adapted to not enable -mrestrict-it by default at all, following what was already done in gcc at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-12/msg00134.html.
Aug 19 2021
Aug 18 2021
Aug 12 2021
Aug 9 2021
Jun 17 2021
Jun 16 2021
Jun 15 2021
Jun 11 2021
Thank you Stephen; LGTM!
Jun 1 2021
May 31 2021
I'm wondering what the rationale for this change is.
If there is a good rationale for this; wouldn't it need to be applied to all target-specific header files, not only the Arm-specific header files?
May 19 2021
LGTM.
May 18 2021
Thanks @danielkiss !
I only have a few nit picky remarks.
Overall looks good!
May 11 2021
May 7 2021
LGTM, thank you Ahmed!
Apr 21 2021
Thanks for this Ahmed!
This mostly looks good to me, I just have a few nit-comments inline.
Apr 16 2021
Apr 15 2021
Apart from maybe needing to run clang-format on the patch, the code changes look good to me.
Before this could be committed, this needs tests.
Apr 12 2021
Mar 25 2021
Mar 24 2021
I approve. Thanks George!
Mar 22 2021
Mar 20 2021
Mar 19 2021
Mar 18 2021
Addressing feedback + also adding a pointer to the various flang and openmp regular sync-ups.
Make capitalization consistent
Mar 17 2021
Thanks Chris.
Now updated following all of your suggestions.