Murali Vijayaraghavan

> so in a world where jumps don't check their targets prior to changing PCC Just to re-iterate, the current spec does exactly that - a bad capability that passes...

> But it's tagged, so the caller didn't fabricate it from nowhere. It got it prior to JIT-ing in my example. (And the revocation mechanism is reliant on this exception...

> Well don't do that then? If you are relying on never executing bad/buggy code, and/or not using straightforward algorithms for revocation, one might as well get rid of most...

> That's an extremely unhelpful reply, and clearly that's not what I'm saying Sorry I didn't mean to be unhelpful or dismissive. I feel this conversation is going in circles....

> in place of the one that the architecture has been designed to support does not work. And what is the current spec supported revocation mechanism for JIT-ed code whose...

> If you're depending on what is fundamentally a debugging feature It could be useful even during a gdb session to know the calling instruction in case of a crash...

> While we're tilting at straw men I agree! The main point seems to get lost: target+2 bytes check is not sufficient to catch exceptions at the caller. There are...

Okay, so what is the procedure to provide feedback or request for changes to this spec?

> I wish I could comment more substantively about this proposal; is the assumption that someone would want to enable a purecap CHERI-RISC-V with no exception support at all? The...

Right. But the way Chapter 3 is organized, it appears as if all the CSRs (and S mode) are necessary to be `Zcheri_purecap` compatible. It would be good to specify...