Re: Multiprogram teaser

[Stan Shebs <stan at codesourcery dot com>]

Tom Tromey wrote:
> > > > > > "Stan" == Stan Shebs <stan@codesourcery.com> writes:
> > > > > >             
>
> Stan> Here's a little teaser showing the results of me flogging GDB's
> Stan> source code.
>
> Delightful.
>
> Stan> Attaching objfile /home/stan/hello to exec /home/stan/hello
> Stan> Attaching objfile /home/stan/goodbye to exec /home/stan/goodbye
> [...]
> Stan> (gdb) exec /home/stan/hello
>
> I'm wondering what happens if you want to start two instances of hello
> at once.
>   
I hadn't thought of that one, no pids to distinguish before they start up...
> I suppose one solution to the UI problems would be to treat each
> separate "exec" (I dunno what you want to call this -- a concept
> encompassing a process, a core file, or an unstarted executable) as an
> object that can be manipulated in its own right.
>   
The idea of an exec is relatively well-defined in GDB, it's what exec.c 
manipulates. It's just that the current code assumes there is only ever 
one, so the state is scattered in random globals, and then things like 
lookup_symbol iterate through all objfiles, secure in the knowledge that 
the first main() found will always be the one wanted.

Breaking the assumption does result in cascading messiness, because of 
those globals is the target stack, built on top of the assumed single 
exec target. Should there be multiple target stacks? Arguments for and 
against.
> So, you could have "info <foo>" to list them, switch between them,
> have "set args" set the arguments for the current one, "run" start one
> or more of them, etc.
>   
I didn't show that, but yeah, I extended "info files" to list them all. 
Its default behavior is a little flawed, in that it wants to show you 
every section of every executable, which can get to be a lot of 
scrolling. :-)

Stan