When building llvm-test-suite with -fptrauth-indirect-gotos, we have incorrect codegen for two tests: we should fail to compile code with label arithmetic, but instead, we emit incorrect instruction sequence.
SingleSource/Regression/C/gcc-c-torture/execute/920302-1: fails during second execute function invocation on this piece of code (which corresponds to 19th line goto *(base + *ip++);). With x10 holding a non-zero integer offset, we try to add that to an already signed pointer and then perform an authenticated branch, which is wrong.
SingleSource/Regression/C/gcc-c-torture/execute/comp-goto-1: fails inside simulator_kernel function on this piece of code (which corresponds to 85..88th lines ending with goto *(base_addr + insn.f1.offset);). With x16 holding an already signed pointer and x11 holding a non-zero offset, we try to add them and get an ill-signed pointer in x14, and then try to perform an authenticated branch on it, which is wrong.
As already pointer in the original PR, not all the cases are handled in terms of not supporting label arithmetic and emitting a compile error: see https://github.com/llvm/llvm-project/pull/97647#discussion_r1687258996. This issue reports particular tests failures for such unhandled cases.
#97647 introduced indirect gotos signing.
When building llvm-test-suite with `-fptrauth-indirect-gotos`, we have incorrect codegen for two tests: we should fail to compile code with label arithmetic, but instead, we emit incorrect instruction sequence.
**SingleSource/Regression/C/gcc-c-torture/execute/920302-1**: fails during second `execute` function invocation on this piece of code (which corresponds to 19th line `goto *(base + *ip++);`). With x10 holding a non-zero integer offset, we try to add that to an already signed pointer and then perform an authenticated branch, which is wrong.
```
adrp x16, 0xaaaaaaab0000
add x16, x16, #0x990
mov x17, #0xb764
pacia x16, x17
add x10, x16, x10
mov x17, #0xb764
braa x10, x17
```
**SingleSource/Regression/C/gcc-c-torture/execute/comp-goto-1**: fails inside `simulator_kernel` function on this piece of code (which corresponds to 85..88th lines ending with `goto *(base_addr + insn.f1.offset);`). With x16 holding an already signed pointer and x11 holding a non-zero offset, we try to add them and get an ill-signed pointer in x14, and then try to perform an authenticated branch on it, which is wrong.
```
adrp x16, 0xaaaaaaab0000
add x16, x16, #0xae0
mov x17, #0xb59f
pacia x16, x17
lsl x11, x10, #46
lsr x12, x10, #52
ubfx x13, x10, #20, #12
add x10, x1, #0x410
add x14, x16, x11, asr #46
and x11, x12, #0x3fc
and x13, x13, #0x3fc
ldr w12, [x8, x11]
add x11, x1, #0x418
mov x17, #0xb59f
braa x14, x17
```
As already pointer in the original PR, not all the cases are handled in terms of not supporting label arithmetic and emitting a compile error: see https://github.com/llvm/llvm-project/pull/97647#discussion_r1687258996. This issue reports particular tests failures for such unhandled cases.
97647 introduced indirect gotos signing.
When building llvm-test-suite with
-fptrauth-indirect-gotos
, we have incorrect codegen for two tests: we should fail to compile code with label arithmetic, but instead, we emit incorrect instruction sequence.SingleSource/Regression/C/gcc-c-torture/execute/920302-1: fails during second
execute
function invocation on this piece of code (which corresponds to 19th linegoto *(base + *ip++);
). With x10 holding a non-zero integer offset, we try to add that to an already signed pointer and then perform an authenticated branch, which is wrong.SingleSource/Regression/C/gcc-c-torture/execute/comp-goto-1: fails inside
simulator_kernel
function on this piece of code (which corresponds to 85..88th lines ending withgoto *(base_addr + insn.f1.offset);
). With x16 holding an already signed pointer and x11 holding a non-zero offset, we try to add them and get an ill-signed pointer in x14, and then try to perform an authenticated branch on it, which is wrong.As already pointer in the original PR, not all the cases are handled in terms of not supporting label arithmetic and emitting a compile error: see https://github.com/llvm/llvm-project/pull/97647#discussion_r1687258996. This issue reports particular tests failures for such unhandled cases.