Re: Towards multiprocess GDB

[Stan Shebs <stan at codesourcery dot com>]

Tom Tromey wrote:
> This is particularly interesting if you are watching a very large tree
> of processes.  It would be nice if gdb did not have eagerly to read
> symbols for every program.
>   
Yes, that would be good. I think that if things like breakpoint 
locations include an exec name, then inferior control need do nothing 
more than catch the fork/exec, and let the programs with nonmatching 
names continue on without further ado.
> Another idea, related to something in HPD, would be to come up with a
> general syntax for naming things -- like "#PID#file.c:function" (or
> what have you) -- so the user can easily embed a context into a name.
> (I dunno if this is useful, I'm just brainstorming a bit.)
>   
We're going to want some sort of syntax, don't want to commit to any 
particular character(s) yet. :-)
> Stan> Conversely, the user will also want a way to take programs out
> Stan> of the debugging session. This is not quite the same as
> Stan> detaching, because the user may want, say, the server to
> Stan> continue doing its serving thing
>
> I don't understand the distinction here.  With 'detach' the server
> would continue serving... what am I missing?
>   
I'm thinking one may want to flush symbol tables, so as to reduce 
ambiguity. Otherwise you could end up with more and more versions of 
main() over time, and very long selection menus in response to "break 
main", but with many or most of the entries being for programs not 
actually being debugged at the moment.
> Stan> Although my inclination is to create a new symbol table for each
> Stan> process' image of each shared library, that may be excessively
> Stan> expensive.
>
> To me this sounds important to solve, though of course I have no
> numbers.  I am just thinking that every program is going to be mapping
> in libc, and it would be great to scale to a large number of inferiors.
> FWIW the particular scenario I am interested in is running "make check"
> in the gcc tree, under gdb, and having it stop only when some
> sub-process gets a SEGV.  So, the question is, how does gdb react to
> thousands of process creations and deletions, how eagerly does it read
> and discard symbol table info, etc.
>   
That's a really great scenario to keep in mind, and totally doable I 
think, though maybe not on the first iteration. :-)

Stan