How to run program functions in gdb on a breakpoint?

Question

I have an array that I am constantly modifying. After my program is finished executing my modifications don't quite do what I want them to do, so my array doesn't turn out the way that I want. I have a function that reads the contents of the array. Is there a way to use gdb and place a breakpoint somewhere, then run my function that reads the content of the array? I want to find out where the problem occurs. Gdb does not let me run "p readArray()". f I have a breakpoint.

Answer 1

Use "commands" to run a command whenever you hit a particular breakpoint. For example, to run the command on the first breakpoint:

(gdb) commands 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
> call readArray()
> end

You can use "info break" to determine the number of the breakpoint you are interested in.

Answer 2

It sounds like what you want is to set a watch on the array. The syntax is watch <expression> - refer to this question for more information on using watches with dynamic arrays (it's C++, but should be the same in C).

Answer 3

Set the breakboint at address. Get the address of your array at a point where you malloc or statically create array and set the breakpoint at address.

break *addr "set breakpoint at address addr"

Answer 4

A 'dirty' method is to modify the program-counter register to the address of a location in your code where the display function is called. Be sure to set a break-point after the call so that you can restore the program-counter to its original value if you want the code to continue correctly thereafter.

Even dirtier, if the function does not take parameters, is to set the program-counter to the address of the first instruction in the function. In this case place a break-point at the return statement and restore the program-counter there, otherwise the return will return to the caller of the function of the first break-point which may not be what you would want.

That said, the debugger is perfectly capable of displaying array contents via a "watch", so unless the content requires specific interpretation to make sense of it, that would surely be a better method?

Another non-debugger work-around would be to have the array implemented as a memory mapped file or shared memory, then use a separate process to map and display the same file or memory. This technique would be OS specific.