Re: Towards multiprocess GDB

[Pedro Alves <pedro@codesourcery.com>]

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
instance.

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

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