[Bug cli/13700] New: should allow CLI to switch thread on event

[Bug cli/13700] New: should allow CLI to switch thread on event

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13700

             Bug #: 13700
           Summary: should allow CLI to switch thread on event
           Product: gdb
           Version: 7.4
            Status: NEW
          Severity: normal
          Priority: P2
         Component: cli
        AssignedTo: unassigned@sourceware.org
        ReportedBy: tromey@redhat.com
    Classification: Unclassified


See:

http://sourceware.org/ml/gdb-patches/2012-02/msg00263.html

and subsequent messages.

It should be possible to let an event select a new thread,
even in non-stop, provided that the last command invoke was
a foreground command, not a background command.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug cli/13700] should allow CLI to switch thread on event

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13700

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #1 from Pedro Alves <palves at redhat dot com> 2012-02-16 15:13:17 UTC ---
I remembered why I never looked back at this.
It is not clear to me we should always do that.

Consider:

 (gdb) next
 * other random thread stops*
 [switched to $random_thread]
 (gdb) foofoo
 * next finishes later *
 (gdb) foofoofoofoo

I think the user may want to stay focused on the "next" instead of
being distracted by the other stop.

Switching focus on "continue" only would be my next idea, but,
I'm still not sure.  The user may "break foo; continue"; and expect
the foo breakpoint to hit, instead of being distracted by other
threads.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug cli/13700] should allow CLI to switch thread on event

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13700

--- Comment #2 from Tom Tromey <tromey at redhat dot com> 2012-02-16 18:08:16 UTC ---
My scenario was something like: debug 'make' in multi-inferior mode,
run it in the foreground, lots of new inferiors are created and destroyed,
then one of them crashes.  Then I got output like this:

[New process 2800]
process 2800 is executing new program: /home/tromey/gnu/archer/Multi/crasher

Program received signal SIGSEGV, Segmentation fault.
0x000000000040047f in main () at crasher.c:5
5      *x = 52;

... but I was actually debugging the original inferior, which is
still running:

 (gdb) info inferior
  Num  Description       Executable        
  7    process 2800      /home/tromey/gnu/archer/Multi/crasher 
* 1    process 2792      /usr/bin/make     

I just found this very surprising.  In fact the first time I didn't realize
what had happened and I assumed there was a gdb bug, because I saw a crash
(which visually is indistinguishable from the familiar single-inferior
single-thread case) and tried to bt:

(gdb) bt
Target is executing.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug cli/13700] should allow CLI to switch thread on event

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13700

--- Comment #3 from Pedro Alves <palves at redhat dot com> 2012-02-16 18:28:08 UTC ---
Irrespective of foreground issues, those messages are confusing with background
commands as well, for not being inferior/thread qualified.
Even with breakpoint hits, you see confusing things like:

(gdb) b 64
(gdb) c -a&
Continuing.
(gdb) 
Breakpoint 2, thread_function0 (arg=0x0) at threads.c:64
64              usleep (1);  /* Loop increment.  */

Breakpoint 2, thread_function0 (arg=0x0) at threads.c:64
64              usleep (1);  /* Loop increment.  */

Breakpoint 2, thread_function0 (arg=0x0) at threads.c:64
64              usleep (1);  /* Loop increment.  */


(that's three threads hitting a breakpoint)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug cli/13700] should allow CLI to switch thread on event

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13700

--- Comment #4 from Pedro Alves <palves at redhat dot com> 2012-02-20 19:10:45 UTC ---
Related, if/when we show the selected thread in the prompt (e.g., "thread N>",
then with:

thread 1> c (or c& or whatever)
Thread 2 [foo bar] received signal SIGSEGV, Segmentation fault.
0x000000000040047f in main () at crasher.c:5
5      *x = 52;
thread 1>

the question of whether to switch the thread on event is no longer one about
confusion/surprise, but about convenience (and that depends on use case).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug cli/13700] should allow CLI to switch thread on event

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=13700

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
FWIW I ran into this again today doing multi-inferior debugging.
The current behavior is quite confusing, given that the mode
I'm using is "set a catchpoint and then continue the entire
tree of processes".

The current behavior would be less confusing
if gdb printed a warning: "hey, even though this breakpoint
hit in inferor N, you're still looking at thread M."

-- 
You are receiving this mail because:
You are on the CC list for the bug.