Re: Multi-exec patches

[Tom Tromey <tromey@redhat.com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Tom> ... which is a little odd, since no build was done.
Tom> And, what's with process 3931 executing /bin/true?
Tom> Am I not debugging the 'make' process?

Pedro> Ah, but you're debugging in all-stop mode.  What this means
Pedro> is that a program exit is a reason to stop everything and report
Pedro> to the user.  This was /bin/true exiting.  Check "info inferiors",
Pedro> and you should still see other inferiors there, waiting for you
Pedro> to tell them to continue execution.

I didn't see anything else in "info inferiors", but I am not sure I am
doing it at the right time.

I made gdb crash while trying it again today:

(gdb) set non-stop on
(gdb) set detach-on-fork off 
(gdb) run 
Starting program: /usr/bin/make 
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Can not resume the parent process over vfork in the foreground while 
holding the child stopped.  Try "set detach-on-fork" or "set schedule-multiple".
Recursive internal problem.
Aborted


I also got this strange result:

(gdb) set detach-on-fork off
(gdb) set schedule-multiple on
(gdb) set non-stop on
(gdb) run
Starting program: /usr/bin/make 
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New process 21131]
Couldn't get registers: No such process.
(gdb) info inf
  Id   Target ID         SSpace Main Program      
* 2    process 21131     2                        
  1    process 21128     1      /usr/bin/make     


Also, "ps" showed me several /usr/bin/make processes still hanging
around from the other day's debugging attempts.

Tom> A minor nit: I think "is executing a new program" would read better.

Pedro> See?  That was the *only* string I changed, and it's picky.  :-)
Pedro> I should have left that out of the patch.  :-)

Hahaha.  I'm sorry about that.  I do try to avoid bikeshedding of this
sort, but now I've discovered that I only *think* I try ;)

Pedro> You need to try it with non-stop mode on.  It should work like you
Pedro> seem to want it to.   See the "bootstrapping" gdb example here:
Pedro>  http://sourceware.org/ml/gdb-patches/2009-06/msg00388.html

Ok, this worked much better.  I was able to interrupt a cc1 process
during make!

I did see this, I don't know if it is intended:

(gdb) kill
Kill the program being debugged? (y or n) y
You can't do that without a process to debug.


After interrupting cc1, I used "quit".  gdb exited, but then the make
resumed in the background.


gdb seems somewhat sluggish when I run 'make' in it.  Perhaps it is just
because my system is under load.

I see now that inferior output is going to be a problem in this mode, at
least when using gdb in a terminal.

I ran into another crash somehow:

../../archer/gdb/thread.c:708: internal-error: finish_thread_state: Assertion `tp' failed.

I don't know whether I can reproduce this one.  I tried setting a
pending breakpoint in c_common_init_options and then running make.

Pedro> ( Long term, I'd very much like to fuse all-stop into non-stop.  That is,
Pedro> implement all-stop mode on top of non-stop+async, and so have make the
Pedro> UI (especially the number of setting required to activate), much reduced.
Pedro> We're still a bit far from that... )

Sounds good.

Tom