Questions about multi-core C debugging and debug_send_command()

[rowbearto]

When I'm doing multi-core C debugging, I understand that I can call debug_remote() multiple times, once for each core.

For being able to choose which core to target a gdb command via something like debug_send_command(), I have some questions:

1) When I provide the "attach_info" to the debug_remote() call, I should provide a unique "session" to each debug session, so that I can target which debug session to send a command to?

2) After a call to debug_remote(), does that make the new session the "current" session (returned by dbg_get_current_session())?

3) As debug_send_command() only sends a command to the "current" session, I should use dbg_session_do_command() instead, where I can provide a "session_id"? This way I can send a command to a specific debug session?

4) I can get the session_id by invoking dbg_find_session() with the session name? This provides good incentive to have different session names for each core?

5) What does it mean for a session to be the "current" one? For example if I called dbg_set_current_session() what does it do besides changing what is returned by dbg_get_current_session()?

6) Is it valid to call dbg_session_do_command() on a session that is not the active/current one?

[Dennis]

1) Yes, each session needs to have a unique name.  You would probably get an error if you tried to create one with the same name as an existing session.

2) Yes, and maybe no.  It would make it the current session, however, if timing works out that another session hits a breakpoint just after you attach, the other session which hit the breakpoint could assume the role of current.

3) Yes, you could use that function, as long as you look up the session ID first.

4) yes

5) The current session is the one that is going to show in the all the debug tool windows (call stack, locals, etc).

6) yes


A final word of warning, don't send commands like "step" or "continue" or "break" manually.  Doing that will get SlickEdit's idea of the debuggee state out of sync with its actual state.