Advertise pointer authentication support to GDB#4073
Conversation
|
Apparently that's already in the tree. |
|
It's part of gdb |
| // PAuth masks. These aren't real registers, so we set the offset/size to 0 | ||
| // and use custom handling in read_register(). | ||
| RegisterInit(DREG_PAUTH_DMASK, RegisterValue("pauth_dmask", 0, 0)), | ||
| RegisterInit(DREG_PAUTH_CMASK, RegisterValue("pauth_cmask", 0, 0)), |
There was a problem hiding this comment.
I don't understand why this is needed. We don't need this for e.g. DREG_FPCR.
There was a problem hiding this comment.
Yeah, not necessary, removed. I got confused and thought that ExtraRegisters was a subset of Registers when it's actually either/or.
We may consider removing the Registers code path and handling everything through what is now ExtraRegisters, which would be renamed to Registers. It would be a bit more code for each currently non-extra register but it would make it clearer how each register is handled.
GDB uses the values of the provided pointer authentication mask registers to mask return addresses from the stack trace. Because we weren't providing these masks, the return addresses in the stack trace were incorrect in programs built with -mbranch-protection=pac-ret, such as most of Fedora. Fix it by advertising pointer authentication to GDB, and providing the correct masks. Fixes the following tests on PAC platforms: fork_exec_info_thr fork_exec_info_thr-no-syscallbuf vdso_clock_gettime_stack vdso_time_stack
|
Looks like CI is failing (some of the tests SIGABRT) but I don't have any failures like that on my end. Would it be possible for someone with access to the CI to take a look? |
I can do that, and I will try to do that soon. But it is relatively easy to replicate the CI environment. We use AWS |
CI runs on Graviton2 and it looks like pointer authentication was added in Graviton3. |
|
Ignore my previous comment about HWCAP2. That's what I get for not double checking Gemini. The cset I just pushed should fix the CI issues. |
|
Thanks for the PR! |
So does it mean that we shouldn't be building with |
|
@rocallahan We should probably bump the runners to Graviton3 instances. |
Maybe we should have both? |
Well we're building with -march=armv8.3-a but running on a processor that only supports the v8.2-A ISA. |
|
Ok I updated the runner function to spawn |
3 participants
GDB uses the values of the provided pointer authentication mask registers to mask return addresses from the stack trace. Because we weren't providing these masks, the return addresses in the stack trace were incorrect in programs built with -mbranch-protection=pac-ret, such as most of Fedora. Fix it by advertising pointer authentication to GDB, and providing the correct masks.
Fixes the following tests on PAC platforms:
fork_exec_info_thr
fork_exec_info_thr-no-syscallbuf
vdso_clock_gettime_stack
vdso_time_stack