public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org
Cc: Tom Tromey <tromey@redhat.com>, Stan Shebs <stanshebs@earthlink.net>
Subject: Re: Toward multicore GDB - Set theory
Date: Fri, 04 Nov 2011 13:20:00 -0000	[thread overview]
Message-ID: <201111041320.05445.pedro@codesourcery.com> (raw)
In-Reply-To: <m34nyksyxf.fsf@fleche.redhat.com>

On Thursday 03 November 2011 21:01:32, Tom Tromey wrote:
> I think in the past we talked about square brackets and prefix.
> How about we consider that as a straw proposal?
> 
> (gdb) [0-13] print x

Yes, I had actually prototyped that yesterday for breakpoints, and it
was easy on top of a bunch of other infrustructure.  (I made `[' a command).

> I think that would suffice for all commands, even breakpoints; though it
> may be slightly confusing that breakpoints "capture" the set while other
> commands operate on them immediately.  If that is too confusing then
> breakpoints could do another syntax, eg:
> 
> (gdb) break [0-13] function         # "semi-prefix"
> (gdb) break function thread [0-13]  # "natural extension"

Breakpoints need two sets.  The trigger set, which is a generalization
of the "break foo thread N", meaning the set of inferiors/threads where
the breakpoint should fire, and, and suspend/stop set, which is the
set of inferiors/threads that should be suspended when the breakpoint
fires.  The HPD "standard" suggests:

[TRIGGER-SET] break {procedure | line | #file#line}
[ {-count n | -if condition} ] [-stop {stop-set | "[]"} ] 

In my prototype I chose to make that (simplified) for GDB (`()''s
means optional):

 [TRIGGER-SET] break -stop [STOP-SET] (--) LINESPEC

That is, put LINESPEC last, so that we can keep supporting
the current form, but avoid more hacks in linespecs like
the special termination for "thread/task/if" in the lexers
--- that wouldn't work for `['.

If you don't specify a [TRIGGER-SET] explicitly, the trigger
set should be the current global set.  I have yet to
specify how that exactly works, but it should be adjustable
with a "focus ITSET" command (whatever the spelling), and
supposedly the "thread" and "inferior" commands will affect
the default set too in some way.

So what I did was define the `[' command to temporarily
override the current global set.  I think that'll work for
other commands too.

Below's what I got now.

(gdb) info threads 
  Id   Target Id         Frame 
  3    Thread 0x7ffff7028700 (LWP 2296) "threads" (running)
* 2    Thread 0x7ffff7829700 (LWP 2295) "threads" thread_function0 (arg=0x0) at threads.c:63
  1    Thread 0x7ffff7fcb720 (LWP 2290) "threads" (running)
(gdb) [.2] break -stop [.3] 63
Breakpoint 4 at 0x40076d: file threads.c, line 63.

Trigger on thread 2 (equivalent to break 63 thread 2), and
when the breakpoint fires, stop thread 3.  Like so:

(gdb) c -a&
Continuing.
(gdb) 
Breakpoint 4, thread_function0 (arg=0x0) at threads.c:63
63              (*myp) ++;
info threads 
  Id   Target Id         Frame 
  3    Thread 0x7ffff7028700 (LWP 2296) "threads" 0x00007ffff78d75ad in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
* 2    Thread 0x7ffff7829700 (LWP 2295) "threads" thread_function0 (arg=0x0) at threads.c:63
  1    Thread 0x7ffff7fcb720 (LWP 2290) "threads" (running)

(gdb) info breakpoints 
Num     Type           Disp Enb Address            What
4       breakpoint     keep y   0x000000000040076d in thread_function0 at threads.c:63
        stop only in trigger-set: [.2]
        suspend all in stop-set: [.3]
        breakpoint already hit 1 time

We can make a breakpoint that stops the world with (recall I
had non-stop on):

(gdb) del 4
(gdb) [.2] break -stop [all] 63
Breakpoint 5 at 0x40076d: file threads.c, line 63.
(gdb) c -a&
Continuing.
(gdb) 
Breakpoint 5, thread_function0 (arg=0x0) at threads.c:63
63              (*myp) ++;
info threads 
  Id   Target Id         Frame 
  3    Thread 0x7ffff7028700 (LWP 2296) "threads" 0x00007ffff78d75ad in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
* 2    Thread 0x7ffff7829700 (LWP 2295) "threads" thread_function0 (arg=0x0) at threads.c:63
  1    Thread 0x7ffff7fcb720 (LWP 2290) "threads" 0x00007ffff7bc606d in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0

Since I've reimplemented all-stop on top of non-stop, when
non-stop is off, not specifying a stop set (or specifying it
as empty, like -stop []) means that all threads
stop by default, e.g., `[.2] break 63', but you can still
(with all-stop) specify a breakpoint that only suspends a
given itset, with:

(gdb) [.2] break -stop [.3] 63
Breakpoint 5 at 0x40076d: file threads.c, line 63.
(gdb) c &
Continuing.
(gdb) 
Breakpoint 5, thread_function0 (arg=0x0) at threads.c:63
63              (*myp) ++;
info threads 
  Id   Target Id         Frame 
  3    Thread 0x7ffff7028700 (LWP 2645) "threads" 0x00007ffff78d75ad in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
* 2    Thread 0x7ffff7829700 (LWP 2644) "threads" thread_function0 (arg=0x0) at threads.c:63
  1    Thread 0x7ffff7fcb720 (LWP 2610) "threads" (running)

So effectively, this ends up as a superset of all-stop/non-stop,
with the non-stop setting controlling the default stop set.

I haven't spent much time on the syntax bits yet (been focusing
on run control infrustructure), so this is obviously not a fully
cooked spec, but I'm mostly following the HPD spec anyway.  :-)

-- 
Pedro Alves

  reply	other threads:[~2011-11-04 13:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-02  0:04 Stan Shebs
2011-11-03 21:01 ` Tom Tromey
2011-11-04 13:20   ` Pedro Alves [this message]
2011-11-07 17:38   ` Joel Brobecker
2011-11-08  1:14     ` Daniel Jacobowitz
2011-11-08  5:17   ` Matt Rice
2011-11-08 14:50     ` Pedro Alves
2011-11-08 15:04       ` Tom Tromey
2011-11-08 15:45         ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201111041320.05445.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb@sourceware.org \
    --cc=stanshebs@earthlink.net \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).