It works in CLI mode, but not in MI : 1) CLI mode : >>>>>> cat t.c #include <stdio.h> int main() { int i = 34; printf ("Hello, i = %d\n", i); } >>>>>> cat .gdbinit break t.c:7 commands echo "=========== I am here ==========\n continue end >>>>>> gcc --version gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51) Copyright (C) 2006 Free Software Foundation, Inc. [ . . . . . . ] >>>>>> gcc -g t.c -o x86.exe >>>>>> x86-gdb x86.exe GNU gdb (GDB) 6.8.50.20090417-cvs Copyright (C) 2009 Free Software Foundation, Inc. [ . . . . . . ] Breakpoint 1 at 0x804839c: file t.c, line 7. (gdb) run Starting program: /home/maxim/W/BUGS/MI_DAVE/x86.exe Breakpoint 1, main () at t.c:7 7 printf ("Hello, i = %d\n", i); "=========== I am here ========== Hello, i = 34 Program exited with code 016. 2) MI mode >>>>>> cat MI_CMD -interpreter-exec console echo -gdb-show prompt -exec-run kill -gdb-exit >>>>>> x86-gdb x86.exe -i=mi <MI_CMD ~"GNU gdb (GDB) 6.8.50.20090417-cvs\n" ~"Copyright (C) 2009 Free Software Foundation, Inc.\n" [ . . . . . . ] (gdb) ^done (gdb) ^done,value="(gdb) " (gdb) =thread-group-created,id="17693" =thread-created,id="1",group-id="17693" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib/ld-linux.so.2",target-name="/lib/ld-linux.so.2",host-name="/lib/ld-linux.so.2",symbols-loaded="0" =library-loaded,id="/lib/libc.so.6",target-name="/lib/libc.so.6",host-name="/lib/libc.so.6",symbols-loaded="0" *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x0804839c",func="main",args=[],file="t.c",fullname="/home/maxim/W/BUGS/MI_DAVE/t.c",line="7"},thread-id="1",stopped-threads="all" (gdb) &"kill\n" ~"Kill the program being debugged? (y or n) [answered Y; input not from terminal]\n" =thread-exited,id="1",group-id="17693" =thread-group-exited,id="17693" ^done (gdb) ^exit
I wonder if this patch would fix it: http://sourceware.org/ml/gdb-patches/2008-07/msg00583.html
(In reply to comment #1) > I wonder if this patch would fix it: > http://sourceware.org/ml/gdb-patches/2008-07/msg00583.html Yes, it seems to work fine. Only, it did not apply directly. I had to modify it like this : Index: gdb/top.c =================================================================== RCS file: /cvs/src/src/gdb/top.c,v retrieving revision 1.163 diff -u -r1.163 top.c --- gdb/top.c 25 Mar 2009 21:42:34 -0000 1.163 +++ gdb/top.c 20 Apr 2009 20:01:45 -0000 @@ -472,6 +472,9 @@ warned = 1; } } + + /* Do any commands attached to breakpoint we stopped at. */ + bpstat_do_actions (); } /* Read commands from `instream' and execute them @@ -518,10 +521,6 @@ } execute_command (command, instream == stdin); - - /* Do any commands attached to breakpoint we are stopped at. */ - bpstat_do_actions (); - do_cleanups (old_chain); if (display_time) So what should be done now ? Is it going to be applied against the top of the GDB FSF tree ?
Subject: Commands attached to a breakpoint do not execute in MI mode > So what should be done now ? Is it going to be applied against the top of the > GDB FSF tree ? Have you run the testsuite against this change?
Hello Nik, > Have you run the testsuite against this change? No I did not. Can you give me a brief instruction, please, on how to run DejaGnu tests against FSF X86 GDB ? I run all kind of tests against GDB, but all these setups are different from native X86 FSF. Thanks, -- Maxim
> > Have you run the testsuite against this change? > > No I did not. Can you give me a brief instruction, > please, on how to run DejaGnu tests against FSF X86 GDB ? It turned out to be very easy. I went to <build>/gdb/testsuite and typed make check With this "top.c" update, there is one extra failure : FAIL: gdb.threads/schedlock.exp: other threads ran - unlocked The whole picture looks like this: Latest X86 FSF : === gdb Summary === # of expected passes 13400 # of unexpected failures 74 # of expected failures 41 # of known failures 61 # of unresolved testcases 3 # of untested testcases 7 # of unsupported tests 8 Latest X86 FSF with "top.c" update : === gdb Summary === # of expected passes 13399 # of unexpected failures 75 # of expected failures 41 # of known failures 61 # of unresolved testcases 3 # of untested testcases 7 # of unsupported tests 8 -- Maxim
As per the mail linked in comment #1 I see this when sourcing commands, where the breakpoint commands aren't run unless an interactive prompt is displayed first. I.E. if I pass `--eval-command='source breakpoint_file_with_commands' --eval-command=run` the commands associated with a breakpoint aren't run, while if I issue the "run" from the interactive prompt they are.
Created attachment 11160 [details] minimal test case This is the source code I'm debugging
Created attachment 11161 [details] The gdb commands I expect to run without pausing for terminal input
Sorry, attachments came before explanation :-/ I have a problem that I believe to be the same as this one. I've attached a MWE and a set of commands for review and reproduction. Description: a "continue" inside a set of commands for a breakpoint is not obeyed until the user hits enter. Furthermore it only happens if I give the run command on the command line vs typing it inside gdb. My command line is: gdb -ex 'source test.gdb' -ex run mwe where "mwe" is built from the first attachment, and "test.gdb" are the commands in the second one. What I expect to happen: when we encounter breakpoint 2, the commands, the last of which is a "c", should be run and the program should continue What actually happens: gdb pauses until I hit "return", then finishes the program If instead I leave off the second "ex" from the command line, and just type "run" inside gdb, it works fine, and if I put the "run" at the end of the sourced file, that also works fine.
Just hit this with GNU gdb (GDB) 9.1.90.20200224-git. Took a while before I assumed this could have been a bug in gdb and found this bug report. Had been searching for a bug in our testing scripts! Is there a gdb command which may trigger this to work which can be -ex'd after sourcing a script and running the target?