Re: Multi-exec patches (Was: [rfc] Infrastructure to disable breakpoints during inferior startup)

[Pedro Alves <pedro at codesourcery dot com>]

On Friday 24 July 2009 23:45:02, Tom Tromey wrote:
> >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
> 
> Tom> I still haven't actually tried it, but I hope to do so soon.
> 
> I tried it a little.

Thank you!

> 
> I can't remember ... should this all work ok on x86 Linux?  I thought
> yes, hence this report, but if not, feel free to just let me know and
> ignore all this.

It should.  Although I've been testing most on x86_64.

> Most of what I've written here seems familiar.  I assume I read it all
> in earlier notes of yours :-)
> 
> 
> The first thing I noticed is that the new features are off by default.

Right.

> I had to:
> 
>     set schedule-multiple on
>     set detach-on-fork off
> 
> to get it to work.  Having it disabled by default is ok as long as it is
> a "technology preview", but if we think it is very solid then I think we
> should enable it by default.
> 
> Having to set 2 options is obscure.  I suppose I didn't really need to
> set both, except my first attempt was to run "make", which tripped over
> the vfork problem.
> 
> 
> I put a gcc I built into my $PATH.  Then I did:
> 
>     $ cd gdbserver
>     $ ../gdb make
> 
> Then I tried various things.
> 
> "run clean" worked ok!  That was cool!
> 
> Then I exited gdb and restarted it and tried a plain "run".  This gave
> me:
> 
>     (gdb) set schedule-multiple 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)
>     [New process 3931]
>     process 3931 is executing new program: /bin/true
>     (no debugging symbols found)
>     (no debugging symbols found)
>     (no debugging symbols found)
> 
>     Program exited normally.
> 
> ... which is a little odd, since no build was done.
> And, what's with process 3931 executing /bin/true?
> Am I not debugging the 'make' process?

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

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

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

> 
> Then I did "run clean":
> 
>     (gdb) run clean
>     Starting program: /bin/true clean
>     (no debugging symbols found)
>     (no debugging symbols found)
>     gcc -c -Wall -g3    -I. -I../../../archer/gdb/gdbserver -I../../../archer/gdb/gdbserver/../common -I../../../archer/gdb/gdbserver/../regformats -I../../../archer/gdb/gdbserver/../../include ../../../archer/gdb/gdbserver/regcache.c
> 
> Here, for some reason, the compile started.  And, gdb forgot that I was
> looking at "make" and ran /bin/true.

This is a consequence of the above.  You're in all-stop mode,
focusing the /bin/true program, and you've told it to run.  You also
have "shedule-multiple on", so what happened is that you're
told 'true' to run, and, all other inferiors that were stopped
also ran.

(also take a look at the set follow-exec-mode setting --- doesn't apply
in this case, but you seem to be expecting something like that.
Disclaimer, I don't claim these new setting and command names to
be perfect.)


> At this point, gdb hangs and cannot be interrupted.  I kill -9'd it.

Hmm, possibly the vfork parent on foreground issue, but I can't tell
immediately why it happened, since the children should have ran too, if
I didn't miss any command you issued.

> If I do the above but remember "file /usr/bin/make", gdb starts make
> again ok and the compile starts.  But, gdb hangs again as above.
> 
> This hang occurs often enough that I couldn't get to other tests, like
> trying to set a breakpoint that would only trigger in cc1.
> 
> 
> Those "(no debugging symbols found)" messages made me want Doug's patch
> more ;)

( :-) Actually, we don't need to whole of Doug's patch for this.  Just the
bit that suppresses these symbol loading messages for "auto-loaded" objfiles. )

> Note that it is entirely possible that the patch applied strangely and I
> introduced some bug that way.  Or, maybe there is some other pilot
> error.

You need to try it with non-stop mode on.  It should work like you
seem to want it to.   See the "bootstrapping" gdb example here:

 http://sourceware.org/ml/gdb-patches/2009-06/msg00388.html

all-stop + synchronous debugging is limited by design, and what we can
do with it.  Note that this behaviour of stopping when a program exits
isn't new at all.  This is how multi-forks always behaved.

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

-- 
Pedro Alves