Re: [PATCH v2 00/85] target/arm: Implement FEAT_GCS

[Richard Henderson <richard.henderson@linaro.org>]

On 8/12/25 22:07, Richard Henderson wrote:
> On 8/12/25 13:46, Thiago Jung Bauermann wrote:
>> Most of the GDB tests pass. The only failure is in a test which sets the
>> GCSPR in a process to a bogus value. This causes the process to get a
>> SIGBUS:
>>
>> (gdb) set $gcspr = 0xbadc0ffee
>> (gdb) continue
>> Continuing.
>>
>> Program received signal SIGBUS, Bus error.
>> normal_function0 () at /path/to/gdb/testsuite/gdb.arch/aarch64-gcs.c:121
>> 121      __asm__ volatile ("ret\n");
>>
>> In the FVP emulator, the process gets a SIGSEGV instead, so that is what
>> my test expects:
>>
>> (gdb) set $gcspr = 0xbadc0ffee
>> (gdb) continue
>> Continuing.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> normal_function0 () at /path/to/gdb/testsuite/gdb.arch/aarch64-gcs.c:121
>> 121      __asm__ volatile ("ret\n");
>>
>> I don't know whether this is a bug or just a different permissible
>> behaviour, in which case I can easily adjust my test to expect either
>> signal.
> 
> I may have forgotten to set the gcs bit in the iss2 field along the unaligned access path. 
>   I'll see if I can verify this hypothesis.

Thanks for the off-list test case.

I now see what the problem is: there is no such thing as an unaligned GCS access.  The 
pseudocode for GetCurrentGCSPointer() forces the low 3 bits to 0.

Thus your bad pointer 0xbadc0fee becomes 0xbadc0fe8, which then produces a SEGV 
referencing a bogus page.

I'll re-work the patch set to correct this.


r~