Multiprogram teaser

Multiprogram teaser

[Stan Shebs]

Here's a little teaser showing the results of me flogging GDB's source 
code. In addition to the fun aspect of listing the main()s of two 
different programs, it points up the the potential confusion of having 
several programs in a session. What I've got so far in my prototype is 
the ability to collect multiple execs from the command line, the 
creation of "exec" objects from which you can select one as "current", 
and some symbol table hacking to restrict lookups to the current executable.

stan@adell:~/mpgdb/linux/gdb$ ./gdb -nx ~/hello ~/goodbye
GNU gdb (GDB) 6.8.50.20080728-cvs
[...]
Attaching objfile /home/stan/hello to exec /home/stan/hello
Attaching objfile /home/stan/goodbye to exec /home/stan/goodbye
(gdb) list main
1    int glob = 45;
2   
3    main() {
4     mailand();
5      foo(glob);
6    printf("goodbye cruel world\n");
7    }
8   
9    foo(int x) {
10      return x + 92;
(gdb) exec /home/stan/hello
Setting current exec to /home/stan/hello.
(gdb) list main
3      if (bar == 0)
4        exit(1);
5    }
6   
7    main()
8    {
9      bar();
10      printf("hello world\n");
11    }
12   
(gdb)


Stan

Re: Multiprogram teaser

[Michael Snyder]

Very teasy.  ;-)

Say, how come you're stan at cs.com?  Was "shebs" taken?
;-)

On Mon, 2008-07-28 at 18:46 -0700, Stan Shebs wrote:
> Here's a little teaser showing the results of me flogging GDB's source 
> code. In addition to the fun aspect of listing the main()s of two 
> different programs, it points up the the potential confusion of having 
> several programs in a session. What I've got so far in my prototype is 
> the ability to collect multiple execs from the command line, the 
> creation of "exec" objects from which you can select one as "current", 
> and some symbol table hacking to restrict lookups to the current executable.
> 
> stan@adell:~/mpgdb/linux/gdb$ ./gdb -nx ~/hello ~/goodbye
> GNU gdb (GDB) 6.8.50.20080728-cvs
> [...]
> Attaching objfile /home/stan/hello to exec /home/stan/hello
> Attaching objfile /home/stan/goodbye to exec /home/stan/goodbye
> (gdb) list main
> 1    int glob = 45;
> 2   
> 3    main() {
> 4     mailand();
> 5      foo(glob);
> 6    printf("goodbye cruel world\n");
> 7    }
> 8   
> 9    foo(int x) {
> 10      return x + 92;
> (gdb) exec /home/stan/hello
> Setting current exec to /home/stan/hello.
> (gdb) list main
> 3      if (bar == 0)
> 4        exit(1);
> 5    }
> 6   
> 7    main()
> 8    {
> 9      bar();
> 10      printf("hello world\n");
> 11    }
> 12   
> (gdb)
> 
> 
> Stan
> 
> 
> 

Re: Multiprogram teaser

[Jeremy Bennett]

On Mon, 2008-07-28 at 18:46 -0700, Stan Shebs wrote: 
> Here's a little teaser showing the results of me flogging GDB's source 
> code. In addition to the fun aspect of listing the main()s of two 
> different programs, it points up the the potential confusion of having 
> several programs in a session. What I've got so far in my prototype is 
> the ability to collect multiple execs from the command line, the 
> creation of "exec" objects from which you can select one as "current", 
> and some symbol table hacking to restrict lookups to the current executable.

Hi Stan,

This looks good, but points up the limitations of line based debugging
once you have to handle multiple processors. Realistically this sort of
approach is going to need some sort of windowing environment to separate
out the information. Do you have a view of how this might look inside
gdbtui or ddd or Eclipse? It might be worth thinking about how GDB would
look debugging a modern mobile phone, with perhaps 5 processors, each
from a different manufacturer.

Best wishes,


Jeremy

-- 
Tel:      +44 (1202) 416955
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com

RE: Multiprogram teaser

[Marc Khouzam]

Hi,

> This looks good, but points up the limitations of line based debugging
> once you have to handle multiple processors. Realistically 
> this sort of
> approach is going to need some sort of windowing environment 
> to separate
> out the information. Do you have a view of how this might look inside
> gdbtui or ddd or Eclipse? 

We are currently preparing Eclipse/DSF to support multi-process debugging,
both locally and remotely.
We should have something workable for September.
But I'm not sure GDB will support this for linux or windows at that time.

Note that I say "multi-process" and not "multi-program".  The reason
is that what we are doing will support multi-debugging using
the 'attach' command.  So, you can imagine having a running system
with many processes, and you could then attach to multiple ones.

Multi-program, gives me the impression that the debugged processes 
will be started by GDB itself.  I believe that is what Stan is 
aiming at, right?  This would also fit in Eclipse/DSF, but is not
in our short term planning.  But maybe later...

Marc

Re: Multiprogram teaser

[Pedro Alves]

On Tuesday 29 July 2008 14:13:40, Marc Khouzam wrote:

> We are currently preparing Eclipse/DSF to support multi-process debugging,
> both locally and remotely.
> We should have something workable for September.
> But I'm not sure GDB will support this for linux or windows at that time.

Remote multi-process for your OS, certainly; linux, we not there yet, but
it's likelly;  Windows, I may get around to work on it, but unless
someone else steps up, I don't see it happen by September.

> Note that I say "multi-process" and not "multi-program".  The reason
> is that what we are doing will support multi-debugging using
> the 'attach' command.  So, you can imagine having a running system
> with many processes, and you could then attach to multiple ones.

Yeah, in your case, all processes share the same program/exec, and its
libraries.  Thinking in unix terms, it's like debugging a bunch of
forks.  I'm going to be pushing remote GDB support for that next.

> Multi-program, gives me the impression that the debugged processes
> will be started by GDB itself.  

Could also be attached processes.  But, in extension to what you/we've
been doing, we'll be able to attach to processes that run different
execs/programs.  Say attach to both /bin/cat and /bin/echo.

> I believe that is what Stan is 
> aiming at, right?  This would also fit in Eclipse/DSF, but is not
> in our short term planning.  But maybe later...

It's the natural extension of what you/we've been doing.  We're
not there yet to start working on the details of what will have
to evolve on the MI side, on top of the multi process extensions
that Vladimir cooked up.

-- 
Pedro Alves

RE: Multiprogram teaser

[Marc Khouzam]

> > We are currently preparing Eclipse/DSF to support 
> multi-process debugging,
> > both locally and remotely.
> > We should have something workable for September.
> > But I'm not sure GDB will support this for linux or windows 
> at that time.
> 
> Remote multi-process for your OS, certainly; linux, we not 
> there yet, but
> it's likelly;  Windows, I may get around to work on it, but unless
> someone else steps up, I don't see it happen by September.

I think it would be nice from a GDB point-of-view, so, it would be nice
if someone from the community would step up :-)

> > Multi-program, gives me the impression that the debugged processes
> > will be started by GDB itself.  
> 
> Could also be attached processes.  But, in extension to what you/we've
> been doing, we'll be able to attach to processes that run different
> execs/programs.  Say attach to both /bin/cat and /bin/echo.

I had also imagined this as multi-process.  You have a bunch of linux
processes already running and you can attach to multiple ones.
Like, say, vi and emacs.  So, multi-process debugging would work for
long-lived processes.

I thought multi-program would launch different programs, which could
then be short-lived.  But that's how I imagined it...

Marc

Re: Multiprogram teaser

[Stan Shebs]

Marc Khouzam wrote:
> Multi-program, gives me the impression that the debugged processes 
> will be started by GDB itself.  I believe that is what Stan is 
> aiming at, right?  This would also fit in Eclipse/DSF, but is not
> in our short term planning.  But maybe later...
>
>   
By "multiprogram" I mean that there can be several different 
executables, each with its own code, symbols, etc. There's no assumption 
about how GDB interacts with the running targets created from the 
executables; it could launch, attach, do target remote, etc.

It's orthogonal to "multiprocess" debugging because you could have one 
executable and be debugging a half-dozen processes created by multiple 
runs of the executable. You could also have a single process whose 
address space includes several different executables, each at a 
different address.

"Multiprocess" is often taken to mean "multiprogram" as well, presumably 
because the case of one executable and multiple processes is not that 
interesting in practice.

GUIwise, I expect that each program will want its own window, since most 
state and context is not going to be shared with other programs. Ideally 
there would be a program/process list with checkboxes so you can 
simul-continue a chosen subset of processes. The list may get long - 
imagine Tom's example of GCC testsuite running under a multiprocess GDB 
that catches every cc1, gas, ld, etc run - that's dozens of programs and 
thousands of processes!

Stan

RE: Multiprogram teaser

[Marc Khouzam]

> By "multiprogram" I mean that there can be several different 
> executables, each with its own code, symbols, etc. There's no 
> assumption 
> about how GDB interacts with the running targets created from the 
> executables; it could launch, attach, do target remote, etc.
> 
> It's orthogonal to "multiprocess" debugging because you could 
> have one 
> executable and be debugging a half-dozen processes created by 
> multiple 
> runs of the executable. You could also have a single process whose 
> address space includes several different executables, each at a 
> different address.
> 
> "Multiprocess" is often taken to mean "multiprogram" as well, 
> presumably 
> because the case of one executable and multiple processes is not that 
> interesting in practice.

From an Eclipse GUI point-of-view (user point-of-view), I get
the impression that the two concepts could be treated 
the same.  The user would be interested in debugging a running/runnable
process. But maybe I'm over-simplifying...

Marc

Re: Multiprogram teaser

[Tom Tromey]

>>>>> "Stan" == Stan Shebs <stan@codesourcery.com> writes:

Stan> The list may get long - imagine Tom's example of GCC testsuite
Stan> running under a multiprocess GDB that catches every cc1, gas,
Stan> ld, etc run - that's dozens of programs and thousands of
Stan> processes!

I just want to be clear -- I read this example on the frysk web site.
I'm not sure who came up with it, but I assume Andrew Cagney.

Anyway, it is very compelling for the gcc hacker in me, so I use it as
an example all the time :-)

Tom

Re: Multiprogram teaser

[Tom Tromey]

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

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.

Tom

Re: Multiprogram teaser

[Stan Shebs]

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