Re: [RFC] thread apply commands change selected frame

[Denis PILAT <denis dot pilat at st dot com>]

Daniel Jacobowitz wrote:
> On Thu, Jan 11, 2007 at 12:24:35PM +0100, Denis PILAT wrote:
> > Hi everyone,
> >
> > I noticed a potential problem in thread.c: the "thread apply" commands 
> > change the selected frame, I think it should not.
> > If you are doing
> >    (gdb) up
> >    (gdb) thread apply all print 1
> >    (gdb) down
> > then the frame selected before the up is not being restored by the down, 
> > we have an error message instead.
>
> Yeah, that's a strange behavior.
>
> > I need your opinion before going ahead in this patch.
>
> It looks right to me.  With a ChangeLog entry and testsuite results
> from some target with threads, it would be OK to commit.
There is one regression in the last test of gdb.threads/threadapply.exp 
since this test does not expect to get the stack frame. With my patch 
the current stack frame is alway printed at the end of a thread apply 
command.
I also changed the semantic since I remove the print_stack_frame from 
the cleanup command so from the error treatment.

I don't catch the original behaviour: it seems to print the stack frame 
only if the last thread we switched to (in the loop) is not the one we 
were before. In that case the user see that because he is in thread 2 
before typing the command:

(gdb) thread apply all p 1
[New Thread 1077955504 (LWP 27106)]
Thread 3 (Thread 1077955504 (LWP 27106)):
$1 = 1
Thread 2 (Thread 1075854256 (LWP 27105)):
$2 = 1
Thread 1 (Thread 1073748160 (LWP 27045)):
$3 = 1
12                      fputc ('x', stderr);

This last line is not printed if current thread is 1 before typing the 
command, that means 3 last line are always inconsistent.

What behavior do we want in normal case (we retrieve the original 
thread) and in case where we can't since the thread has died for instance ?

--
Denis