[Lldb-commits] [lldb] [lldb] Introduce Process::FixAnyAddressPreservingAuthentication (PR #159785)

[David Spickett via lldb-commits]

DavidSpickett wrote:

> In a very ideal world, I would love if we could not strip anything, ever. But this places some burden on codegen of the expression evaluator, for all languages and all ABIs. I don't think it's doable right now.

Yes we're getting into a pointers as capabilities sort of model, except they don't always have the same contents like CHERI does and then we're tracking what's essentially provenance to say what's in the unused bits. Which we might have to do one day but I'd prefer to put it off as long as possible.

> We could also just say "FixAddressForExpressionEvaluation", given how that's the only use case I know of today.

This is fine with me. It's for code generation and expression evaluation is our only code generation (ignoring the IR interpreter).

> A little bit of background, I think everyone understands the basic idea of what Felipe is doing here & why, but I think outlining where we are could be helpful.

I haven't seen anyone deploying MTE or PAC this extensively on Linux, but this all fits with my theoretical understanding of it.

So there are times when you know you have to strip the PAC bits, because the loads do not have a preceding auth.
But also, there are times when you do need to keep the PAC bits, because the loads **do** have a preceeding auth, right?

Like in your example where you JIT extra code to sign the pointers. You do that because the code that uses them expects to be able to authenticate them.

So how do we discriminate between those 2 scenarios? Or do we not. Do the pointers get stripped by the method this PR adds, then the extra code resigns it in-process.

https://github.com/llvm/llvm-project/pull/159785