This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Multi-exec patches (Was: [rfc] Infrastructure to disable breakpoints during inferior startup)
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