Which are the registers that are most important to contain in the stop notification expedited registers section?
I’m adding tests for the ones considered essential. I right now am checking for these generic registers: pc, sp, fp.
I think you mentioned it would be nice to have some of the arg registers as well? Anything else?
The tests go upstream in llvm.org svn for debugserver, and the llgs tests are enabled in the llgs branch and then I use that to drive the llgs implementation.
The goal is that lldb won't need to ask for any additional register values at a typical stop with the command line lldb unless the user issues additional commands. Obviously fp, pc, sp are needed. Sometimes the function arguments (which lldb will print with the frame format) are still in registers -- so we include the argument registers.
In performance tuning with iOS, we've consistently found that the size of the packets is not particularly important - but the number of packets is critical. I think this will be typical of remote communication with devices where there may be several layers involved with the communication. So it's better to include extra registers in the stop packet that lldb might need than to have lldb ask for them individually.
You could argue that you should just throw all of the GPRs in the stop packet. Empirically, we've found that the sp/pc/fp/arg regs are enough and we've never gone all the way and included all of them. Maybe with armv7 where the gpr is relatively small in size we include them all. The smart play is probably just to throw them all in there, even on arm64 where you have 32 GPRs.
A good example of the cost of packet-size vrs. number-of-packets was a little performance tuning I did recently. We had a problem where large memory reads from an iOS device were slow -- reading, say, 6MB of heap. I made three changes to lldb/debugserver that got us about 12x faster reading the same memory from a device: added a binary "x" read memory packet (instead of ascii-hex representations of the memory, so reducing the # of bytes sent by half), stopped adding large memory read data to lldb's memory cache, and went from 512-byte memory reads to 128kbyte memory reads. I didn't try to tease apart which of these were responsible for the performance bump, but I'm willing to bet it was the increase in the size of the memory reads and the reduction in the number of packets required.