The documentation states -batch has the following effect: "Exit with status 0 after processing all the command files specified with `-x' (and all commands from initialization files, if not inhibited with `-n'). Exit with nonzero status if an error occurs in executing the gdb commands in the command files." The following test demonstrates that it is in fact not the case: $ gdb -batch -x "gdb.script" with a file gdb.script containing the line: file toto (of course toto doesn't exist, to raise an error). The output is: gdb.script:1: Error in sourced command file: toto: No such file or directory. Displaying the exit status shows that is is in fact 0. $ echo $? 0
I needed the documented behavior but failed because of this bug. I tried it on: x86_64-linux-gnu version 7.4.1 sparc-sun-solaris2.10 version 6.3 host=i686-pc-mingw32 target=arm-none-eabi version 7.5.1 host=i686-mingw32 target=arm-none-eabi version 7.2 All with the same (bad) result. Since the original bug is quite old, is there a work-around?
Same here. I tested it with gdb 7.9.1 on Archlinux on a x86_64 laptop.
By quick analysis, it looks like the problem resides at line main.c:1137 (I am looking at the source-code in gdb 7.9.1). It looks to me that the error values returned by the catch_command_errors_const is ignored. In case of errors, the file is parsed until the end no matter what, and gdb returns always 0 because the script was executed until the end. As a consequence, I believe that quit_force should, at least, return the last error returned by the catch_command_errors_const, or "1" in case of an error. If you are interested, I could try to provide a patch. Thanks && Cheers. A.
*** Bug 18488 has been marked as a duplicate of this bug. ***
Created attachment 8343 [details] Attempt to fix the -batch issue I am uploading an example of what could, in principle, fix the issue at least in this case. I have tested the patch only on my laptop (Archlinux, x86_64) so I do not pretend this is a general and acceptable solution. However, it should help to prove my point. I hope this can help further investigation in the issue.
The master branch has been updated by Gary Benson <gary@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b0f492b90f3d13da8ac80437e6ecb9a87db4a75b commit b0f492b90f3d13da8ac80437e6ecb9a87db4a75b Author: Gary Benson <gbenson@redhat.com> Date: Wed Aug 29 16:11:50 2018 +0100 Indicate batch mode failures by exiting with nonzero status This commit causes GDB in batch mode to exit with nonzero status if the last command to be executed fails. gdb/ChangeLog: PR gdb/13000: * gdb/main.c (captured_main_1): Exit with nonzero status in batch mode if the last command to be executed failed. * NEWS: Mention the above. gdb/testsuite/ChangeLog: PR gdb/13000: * gdb.base/batch-exit-status.exp: New file. * gdb.base/batch-exit-status.good-commands: Likewise. * gdb.base/batch-exit-status.bad-commands: Likewise.
(In reply to Sourceware Commits from comment #6) > The master branch has been updated by Gary Benson <gary@sourceware.org>: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=b0f492b90f3d13da8ac80437e6ecb9a87db4a75b > > commit b0f492b90f3d13da8ac80437e6ecb9a87db4a75b > Author: Gary Benson <gbenson@redhat.com> > Date: Wed Aug 29 16:11:50 2018 +0100 > > Indicate batch mode failures by exiting with nonzero status > > This commit causes GDB in batch mode to exit with nonzero status > if the last command to be executed fails. > > gdb/ChangeLog: > > PR gdb/13000: > * gdb/main.c (captured_main_1): Exit with nonzero status > in batch mode if the last command to be executed failed. > * NEWS: Mention the above. > > gdb/testsuite/ChangeLog: > > PR gdb/13000: > * gdb.base/batch-exit-status.exp: New file. > * gdb.base/batch-exit-status.good-commands: Likewise. > * gdb.base/batch-exit-status.bad-commands: Likewise. Was fixed with this commit.