https://github.com/jasonmolenda approved this pull request.
LGTM. The `jThreadsInfo` memory is expedited for the entire stack walk on all
threads at a public stop (using a mostly-correct stack frame walk), but at
private stops in the stop packet (e.g. `process plugin packet send ?`), we
expedite the memory of two stack frames for lldb's internal stepping logic
reasons,
```
send packet: $vCont;s:485550#2d
read packet: $T05thread:485550;threads:485550;thread-pcs:1868522ac[...]
memory:0x16fdfecc0=d0ecdf6f010000007404000001000000;memory:0x16fdfecd0=50f3df6f01000000807e5c8601000000;
send packet: $jThreadsInfo#c1
[...]
"memory":[{"address":6171913408,"bytes":"d0ecdf6f010000007404000001000000"}],{"address":6171913424,"bytes":"50f3df6f01000000807e5c8601000000"}],{"address":6171915088,"bytes":"00000000000000000000000000000000"}]]}]]
```
do you think it's worth testing that the stack frame memory is correctly
expedited in the stop reply packet in this test, too? If we ever regressed
that, it would slow every private stop in lldb.
https://github.com/llvm/llvm-project/pull/216165
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
