Re: [RFC] thread apply commands change selected frame

Denis PILAT
2007-01-24T10:42:59Z

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