Re: Problem with using -exec-interrupt in async mode

Re: Problem with using -exec-interrupt in async mode

[Jan Vrany]

Hi, 

On Wed, 2015-03-04 at 08:41 +0000, Pedro Alves wrote:
> Hi Jan,
> 
> On 03/04/2015 07:16 AM, Jan Vrany wrote:
> 
> > My question is: am I doing something wrong, did I misunderstood the 
> > documentation or is it a bug? If it's not a bug, how can I "break"
> > inferior execution using MI only?
> 
> It's a bug -- Simon filed PR 18077 for it:
> 
>  https://sourceware.org/bugzilla/show_bug.cgi?id=18077
> 

Ah, too late. Simon was faster :-) Looking at the code it seems that
-exec-run actually does the same as "r &" CLI command so I'll resort to
that for now. Thanks! 

Jan

Re: Problem with using -exec-interrupt in async mode

[Mainuddin Ahmad Jonas]

Jan Vrany <jan.vrany <at> fit.cvut.cz> writes:

> 
> Hi there, 
> 
> I'm building a little custom debugging tool around GDB using MI. 
> One problem is that -exec-interrupt does not seem to work properly
> even if target-async (mi-async in 7.9) is used. 
>

Hi,

I am facing the exact same issue with GDB 7.10.1. It seems to me
"-gdb-set mi-async on" fails to execute programs in the background.

Jonas

Re: Problem with using -exec-interrupt in async mode

[Pedro Alves]

Hi Jan,

On 03/04/2015 07:16 AM, Jan Vrany wrote:

> My question is: am I doing something wrong, did I misunderstood the 
> documentation or is it a bug? If it's not a bug, how can I "break"
> inferior execution using MI only?

It's a bug -- Simon filed PR 18077 for it:

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

Thanks,
Pedro Alves

Problem with using -exec-interrupt in async mode

[Jan Vrany]

Hi there, 

I'm building a little custom debugging tool around GDB using MI. 
One problem is that -exec-interrupt does not seem to work properly
even if target-async (mi-async in 7.9) is used. 

Example: 
I have a simple test program that writes a prompt, then waits
for user input by means of fgetc() and then prints good bye and
exits. 
When I start it using -exec-run it starts and prints the prompt. 
Then I want to "break" while waiting for an IO, so I issue 
"-exec-interrupt --all". However, the command is not processed
until inferior finishes. i.e., when I send a key on inferiors tty
then I get all the events that inferior finishes plus response to
-exec-interrupt command ("^done"). 
I would expect to get the response "immediately" as well as events 
about thread being stopped. Full session transcript of commands issued
and responses got are below. 

Interestingly, if I issue a CLI command "r &" intead of "-exec-run" it
works as expected, i.e., I get the response for "-exec-interrupt" 
immediately after issuing. Full session transcript when using "r &" is
also below. 

My question is: am I doing something wrong, did I misunderstood the 
documentation or is it a bug? If it's not a bug, how can I "break"
inferior execution using MI only?

Thanks a lot!
Best, Jan


=====
Session records (<<< responses sent by GDB, >>> commands sent to GDB)
Session with MI only (not working as I would expect)
<<<
=thread-group-added,id="i1"
(gdb) 

 >>>
1-inferior-tty-set /dev/pts/3
 <<<
1^done
(gdb) 

 >>>
2-gdb-set target-async on
 <<<
2^done
(gdb) 

 >>>
3-file-exec-and-symbols /home/jv/tests/c/press_any_key
 <<<
3^done
(gdb) 

 >>>
4-exec-run
 <<<
=thread-group-started,id="i1",pid="25021"
=thread-created,id="1",group-id="i1"
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
4^running
*running,thread-id="all"

 <<<
(gdb) 

 >>>
5-exec-interrupt --all        



=====
Session with using "r &" instead of "-exec-run" (works as expected)

<<<
=thread-group-added,id="i1"
(gdb) 

 >>>
1-inferior-tty-set /dev/pts/2
 <<<
1^done
(gdb) 

 >>>
2-gdb-set target-async on
 <<<
2^done
(gdb) 

 >>>
3-file-exec-and-symbols /home/jv/tests/c/press_any_key
 <<<
3^done
(gdb) 

 >>>
4r &
 <<<
&"r &\n"
~"Starting program: /home/jv/tests/c/press_any_key \n"
=thread-group-started,id="i1",pid="25007"
=thread-created,id="1",group-id="i1"
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
4^running
*running,thread-id="all"

 <<<
(gdb) 

 >>>
5-exec-interrupt --all
 <<<
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="0",thread-group="i1"
5^done
(gdb) 

 <<<
~"\nProgram received signal "
~"SIGINT, Interrupt.\n"
~"0x00007ffff7b0c5c0 in read () from /lib/x86_64-linux-gnu/libc.so.6\n"
*stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",frame={addr="0x00007ffff7b0c5c0",func="read",args=[],from="/lib/x86_64-linux-gnu/libc.so.6"},thread-id="1",stopped-threads="all",core="3"

 >>>
6-stack-info-depth --thread 1 100
 <<<
6^done,depth="5"
(gdb) 

 >>>
7-stack-list-frames --thread 1 0 4
 <<<
7^done,stack=[frame={level="0",addr="0x00007ffff7b0c5c0",func="read",from="/lib/x86_64-linux-gnu/libc.so.6"},frame={level="1",addr="0x00007ffff7aa83f0",func="_IO_file_underflow",from="/lib/x86_64-linux-gnu/libc.so.6"},frame={level="2",addr="0x00007ffff7aa921e",func="_IO_default_uflow",from="/lib/x86_64-linux-gnu/libc.so.6"},frame={level="3",addr="0x00007ffff7aa4a8e",func="getc",from="/lib/x86_64-linux-gnu/libc.so.6"},frame={level="4",addr="0x0000000000400602",func="main"}]
(gdb) 

 >>>
8-thread-select 1
 >>>
9-stack-select-frame 0
 >>>
10-stack-list-variables --thread 1 --frame 0 --simple-values
 <<<
8^done,new-thread-id="1",frame={level="0",addr="0x00007ffff7b0c5c0",func="read",args=[],from="/lib/x86_64-linux-gnu/libc.so.6"}
(gdb) 

 <<<
9^done
(gdb) 

 <<<
10^done,variables=[]
(gdb) 

 >>>
11-exec-continue
 <<<
11^running
*running,thread-id="all"

 <<<
(gdb) 

 <<<
(gdb) 

 <<<
~"[Inferior 1 (process 25007) exited with code 06]\n"
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="06"
*stopped,reason="exited",exit-code="06"