Brenda J. Butler
Brenda J. Butler

Reputation: 1485

using the "return" command in a gdb script

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

Answers (1)

ks1322
ks1322

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

Related Questions