Towards multiprocess GDB

Pedro Alves
Sat Jul 19 03:53:00 GMT 2008

A Friday 18 July 2008 23:27:58, Stan Shebs wrote:

> I'm not sure it's going to be that big of a change actually. Once
> behavior has been directed to the right objects internally, they will do
> what they're doing now. Most symbol handling is objfile-relative for
> instance, adding a new set of objfiles for a different exec isn't going
> to affect that code.

You seem to be thinking of the symbol handling code only.

The thing I see requiring architecting, is the target stack.

Currently, it's only layed out for the single executable + single
process case.

For starters, I'll try to give a simple example.

Imagine you're debugging simultaneously these cases below:

1) Linux native non-threaded app.  The current target is a squashed
view of:

 linux-nat    process_stratum
 exec         file_stratum

2) Linux native multi-threaded app, loads libthread_db for the thread
support.  The current target is a squashed view of:

 linux-thread-db    thread_stratum
 linux-nat          process_stratum
 exec               file_stratum

3) Linux native threaded app, but loads another thread support lib.

 linux-other-thread-db    thread_stratum
 linux-nat                process_stratum
 exec                     file_stratum

4) Linux native non-threaded app, doing reverse debugging.

 record                   record_stratum
 linux-nat                process_stratum
 exec                     file_stratum

 (There are OSs where this is more common.)

It seems to me that each process should have its own target stack

We could split target_ops in two and share the ops part
between instances, but still the target_ops rw data needs to be

Note that I'm not even considering multi-process,multi-exec,single
remote target connection, where things get even dirtier, or even
native process + remote process debugging simultaneously.

There are other issues around the target stack that need
resolution, but this issue above seems crucial to have in
mind first.

Pedro Alves

More information about the Gdb mailing list