[Lldb-commits] [lldb] [lldb] Remove UnwindPlan::Row shared_ptrs, lite (PR #134081)

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Thu Apr 3 06:46:27 PDT 2025


labath wrote:

> LGTM. I got kind of excited by the value semantics, but I don't know how many copies we're talking about and this is an established way to guarantee pointer stability.

Yeah, this definitely feels less satisfying. It also feels a bit path-dependent, as I don't think we'd fret over this if Rows were values from the beginning.

So, I tried to make a small benchmark, and according to the results, copying a Row object with three register values (which is one more than what I'd expect for a typical first/last row of an unwind plan) takes about 50 *nano*seconds. Copying a row with 100 registers (which is like more that most architectures have) takes ~three *micro*seconds.

With that in mind, maybe we do want to go ahead with https://github.com/llvm/llvm-project/commit/d55a1ba1a9f4d5201eb578e247a077c1484b251c ?



> LGTM. I'm not sure if it's feasible, but perhaps x86AssemblyInspectionEngine could store an Index to the Row instead? Then you wouldn't need pointers or worry about their stability. UnwindPlan would just need to hand back some kind of row pointer/reference on demand and those should not be stored.

That doesn't quite work here because the code in question is inserting new rows into the middle of the unwind plan, so the index changes as well (for the last row, at least). I mean, I suppose you could try and keep the index up to date, but that's going to be very fragile.

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


More information about the lldb-commits mailing list