illumos gate

SmartOS OS-5852

KMDB often gets "stuck" after a :c with:

[51]> :c
kmdb: single-step stop on miscellaneous trap
kmdb: target stopped at:
xc_serv+0x109:  movl   0x654(%r13),%eax

What appears to be happening here is (for example).

1. We set a breakpoint on a frequently-triggered breakpoint, such as hat_switch().
2. One CPU hits it, and comes through kdi_cmnint to kaif_main_loop(), and is assigned to be master.
3. Simultaneously, another CPU hits the breakpoint, and takes the same path. However, the master is already assigned, so this CPU ends up in kaif_slave_loop(). Note that interrupts are disabled. Also note, since we're now a slave, we've effectively lost the breakpoint event, and we won't ever see it in KMDB.
4. The master now calls kmdb_kdi_stop_slaves(..., 1). This cross-calls to all slave CPUs, including the one above. But interrupts are disabled while in the slave loop.
5. We choose to continue in KMDB, and resume all our CPUs back into the kernel.
6. At some point, our previous slave enables interrupts, and immediately takes the kdi_slave_entry cross-call.
7. It reaches kaif_main_loop(), becomes the new master, and drops into the prompt.

At this point, KMDB is confused, since we appeared as if from nowhere.

If we modify kdi_slave_entry to mark the CPU as a slave, and kaif_main_loop() to ignore spurious entries like this, we are good.

While we're here, we'll also:

1. add a kdiregs_t struct to make reading of ->krs_gregs much easier.
2. Fix kdi_slave_entry for better crumb entries, and also make sure KDIREG_SAVPC isn't the old value of %ss after we do the switcheroo described there.