libunwind: Don't save/restore DDC for RISC-V CheriABI.

[bsdjhb]

Since the register doesn't have a DWARF number, the compiler will
never emit any rules in .eh_frame to unwind its value, so it will
always be restored to the value at the time the exception is thrown.

[jrtc27]

This is an ABI break but I suspect we have nothing other than gdb that would care, which is hybrid anyway? Maybe parts of Qt have knowledge of libunwind, but @pentelbart is about the only user of that on CHERI-RISC-V (LLVM itself also does but only ever treats the context as an opaque pointer/handle, it never dereferences it, and purecap LLVM remains in my experimental local branch), so I think this breakage is fine.

[bsdjhb]

GDB doesn't know/care about unwind cursor layout. It knows about signal frame layouts and sometimes knows some bits about longjmp buffers (but even then it only cares about the location of the PC for software single stepping, not the full layout).

[jrtc27]

GDB doesn't know/care about unwind cursor layout. It knows about signal frame layouts and sometimes knows some bits about longjmp buffers (but even then it only cares about the location of the PC for software single stepping, not the full layout).

I thought it did though and that's why aarch64 GDB was segfaulting when run with a hybrid libunwind when it had erroneously started saving/restoring capabilities?

[bsdjhb]

Hmmm, it uses C++ exceptions and I think the unwind changes in morello-dev just broke C++ exception handling for hybrid at the time. GDB was just the first program we ran under Morello that used exceptions. devd uses C++, but not exceptions IIRC. I'd have to think more about why that broke though as in theory I think the _cxa_*() routines are what allocate exception objects (which are what contain a unw_cursor_t IIRC) so it should only be libcxxrt and libunwind that need to be in sync. Hmm, I guess the libthr does use libunwind directly as well for the unwinding it does in pthread_exit() to run destructors.

[pentelbart]

Maybe parts of Qt have knowledge of libunwind, but @pentelbart is about the only user of that on CHERI-RISC-V

AFAIK it's not used in the parts of Qt that I'm using (I think it's just in the WebEngine/Chromium stuff).

[bsdjhb]

Ping.

[arichardson]

Why does context shrink by two but cursor only by one? But there should be static_assert()s so it must be fine.

[jrtc27]

Hm, I wonder if I mis-counted before, I'd expect it to always be even for CHERI

[bsdjhb]

I think it's probably because of padding.

[bsdjhb]

Hmm, so here is the "old" cursor layout:

(gdb) ptype /o libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_riscv>
/* offset    |  size */  type = class libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_riscv> 
    [with A = class libunwind::LocalAddressSpace, 
         R = class libunwind::Registers_riscv] 
        : public libunwind::AbstractUnwindCursor {
                         private:
/*   16      |    16 */    class A &_addressSpace;
/*   32      |   784 */    R _registers;
/*  816      |   144 */    unw_proc_info_t _info;
/*  960      |     1 */    bool _unwindInfoMissing;
/*  961      |     1 */    bool _isSignalFrame;
/* XXX 14-byte padding */

                           /* total size (bytes):  976 */
                         }

That should result in 976 / 8 == 122 for the cursor size. I'm not sure why this is not tripping up the assertion in the current code. The new size is 960 bytes which results in the 120 in this commit.

Humm, the existing RISC-V world builds with this set to 122 as well as 121. Given how picky the check_fit<> template has been in the past, I don't know why.

Oh:

struct __attribute__((aligned(sizeof(void*)))) unw_cursor_t {
  uint64_t data[_LIBUNWIND_CURSOR_SIZE];
};

That alignment means that too-small values can work since it gets padded out. This is the existing unw_cursor_t:

(gdb) ptype /o unw_cursor_t 
/* offset    |  size */  type = struct unw_cursor_t {
/*    0      |   968 */    uint64_t data[121];
/* XXX  8-byte padding */

                           /* total size (bytes):  976 */
                         }

[bsdjhb]

This is probably also my fault as I probably just used the smallest value which satisfied the assertion failure when doing RISC-V the first time.

[jrtc27]

I feel like I was the one responsible for this code. I probably did something stupid like work out how many pointers there were in the struct and just add that on again, forgetting about padding for alignment.

[jrtc27]

Retracting approval for now; will work out tomorrow what's up with the cursor/context sizes

[jrtc27]

I feel like I was the one responsible for this code. I probably did something stupid like work out how many pointers there were in the struct and just add that on again, forgetting about padding for alignment.