\nIt appears that the real reason of success exit code of the program were some bugs in parsing gdb output. Anyway using -return-child-result
and analyzing gdb exit code instead, is less error prone than parsing text output, I guess.
\n\nIs there something special that has to be done to make the "return"\ncommand work in a gdb script?
\n
It appears that no, but there are exceptions for commands that resume execution, see How to print Entering and Leaving for a function in gdb command? for details.
\n","author":{"@type":"Person","name":"ks1322"},"upvoteCount":1}}}Reputation: 1485
I'm trying to automate a test where I make a function return an error. But the gdb "return (int) 22" command does not seem to be executed, and the program exits with a success code. Is there something special that has to be done to make the "return" command work in a gdb script? Here is the gdb script I'm using:
set width 0
set height 0
set confirm off
set pagination off
set verbose off
set breakpoint pending on
set args the program args
break file.c:function_in_which_to_break
commands 1
return 22
continue
end
run the program args
quit
I would run the program with the following gdb command line:
gdb --batch --command=rc my_program
The desired behaviour is that "function_in_which_to_break" returns 22. The rest of the code will keep passing that up the call stack until the program exits and the exit code of the program should be 22.
The actual behaviour is that the exit code of the program is success.
When I run the program under gdb in a terminal (with command
gdb --args my_program the program args
), break at file.c:function_in_which_to_break by typing in "break file.c:function_in_which_to_break" and run, the program does break there. Then when I type in "return 22" and "continue", the program behaves as I expect, the function returns 22, the program returns 22 and the failure that I expect is shown.
UPDATE: When I said the program returns "success", I meant gdb reported that the child returned success. And when I said the program returns 22, I mean gdb reports that the child returns 22 (actually it says "exited with code 026"). gdb itself returns success in both cases.
UPDATE 2: I found some errors in the automation around the gdb invocation - looking for the "exited with code 026" in a file with misspelled name, calling a misspelled gdb-rc script, stupid things like that. Once those were fixed, the gdb script file with the return statement among the commands seems to work. So as soon as someone writes up an answer like "return commands should work the same as all the other commands" I will accept it. @ks1322
Upvotes: 1
Views: 1659
Reputation: 35845
The actual behaviour is that the exit code of the program is success.
According to documentation, you should also run gdb with -return-child-result
option to get return code of the process being debugged:
-return-child-result
The return code from GDB will be the return code from the child process (the process being debugged), with the following exceptions:
GDB exits abnormally. E.g., due to an incorrect argument or an internal error. In this case the exit code is the same as it would have been without ‘-return-child-result’.
The user quits with an explicit value. E.g., ‘quit 1’.
The child process never runs, or is not allowed to terminate, in which case the exit code will be -1.
This option is useful in conjunction with ‘-batch’ or ‘-batch-silent’, when GDB is being used as a remote program loader or simulator interface.
UPDATE:
It appears that the real reason of success exit code of the program were some bugs in parsing gdb output. Anyway using -return-child-result
and analyzing gdb exit code instead, is less error prone than parsing text output, I guess.
Is there something special that has to be done to make the "return" command work in a gdb script?
It appears that no, but there are exceptions for commands that resume execution, see How to print Entering and Leaving for a function in gdb command? for details.
Upvotes: 1