This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

>>>>> "Tom" == Tom Tromey <> writes:

Tom> I still haven't actually tried it, but I hope to do so soon.

I tried it a little.

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.

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

    (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?

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

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.

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

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 ;)

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]