Re: Towards multiprocess GDB

[Stan Shebs <stan@codesourcery.com>]

Paul Koning wrote:
>>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:
>>>>>>             
>
>  Stan> When it's time to run, the user will want the ability to run
>  Stan> anywhere from one to all of the programs, each with its own
>  Stan> argument list. It should be possible to do this with a single
>  Stan> command, so that the user isn't scrambling to put in all the
>  Stan> run commands quickly enough.
>
> Nice.
>
> Do we need a way to specify a different environment for each program?
>   
Yep, "path" and "set environment" and friends will all need per-program 
controls.
>  Stan> Implementationwise, we will need to replace the single exec
>  Stan> target with a list of execs, and modify symbol machinery to
>  Stan> support a many-many relationship between programs and symbol
>  Stan> tables. Although my inclination is to create a new symbol table
>  Stan> for each process' image of each shared library, that may be
>  Stan> excessively expensive.
>
> Indeed it might be excessive.  Avoiding it means adding the notion of
> per-program offsets, so program A can map library L at offset X, while
> program B maps that same library at offset Y.
>   
Yeah, I'm not yet sure whether we can do it without having to modify all 
the symbol lookup sites. It might make sense to have new symbol table 
objects that consist of process, offsets, and link to old-style symbol 
tables.
>  Stan> In addition to thoughts on desired user interface, I would
>  Stan> welcome suggestions on how to add this feature incrementally;
>  Stan> the abovementioned bits are a lot to add all at once!
>
> You mentioned threads in passing.  Those are still needed, so you need
> to allow multiple programs each of which may have multiple threads.
>   
That's right. In a way execution control is in better shape for this 
than other areas, because it's already had some hacking to facilitate 
listening to multiple issuers of events and such.

Stan