0

In debug mode using gdb, I can see that a function is consuming a variable, called h. I would like to know which gdb command to use to find the location (i.e. declaration of the variable or definition of another function calculating the variable) in the source code where h is calculated before being consumed by the said (second) function.

(gdb) p h

$1 = 2.556769473467e+33

(gdb) "a command to show the function that calculated h"

Rebel
  • 472
  • 8
  • 25
  • not really clear, gdb is not parsing sources, maybe `watch` can help but you will maybe not see the "code" anyway – OznOg Feb 02 '23 at 18:00
  • @OznOg, I tried watch but it doesn't show the function responsible to calculate h. – Rebel Feb 02 '23 at 18:02
  • 1
    There is no such command in gdb. – Sam Varshavchik Feb 02 '23 at 18:18
  • 2
    if you have a variable h, simply looking at the code should tell you what could possibly initialised or assigned to it. – Neil Butterworth Feb 02 '23 at 18:18
  • @NeilButterworth, it is a very large and complicated source code consisting of few hundreds of files .cpp and .hpp all working together to make a software. – Rebel Feb 02 '23 at 18:27
  • 2
    Not possible to get exactly what you want, but you may have the ability to place a breakpoint on change of memory for that variable or a reverse GDB that allows you to step backward. – user4581301 Feb 02 '23 at 18:28
  • 1
    @Ash well, this is what programming is all about, i'm afraid. but if you set some sort of watch on the variable, and get it to break in the debugger, you should be able to see the functions that may have changed it in the call stack. – Neil Butterworth Feb 02 '23 at 18:32
  • 1
    Ash, what you just described is pretty much software in general. You know the variable, `h` (which is a name so bad I'd call it a defect in any function longer than a few lines), and should be able to track down who uses it. Except the variable's name is ing `h`, so even the easy stuff like `grep`ing to see where the variable shows up can't help much. – user4581301 Feb 02 '23 at 18:33
  • @NeilButterworth, some of the files are write-protected and I cannot change. This variable h is being used in one of these files. This means that the best I can do is to assume h got a wrong value as opposed to doubting the files that I cannot change. But, I see your point. – Rebel Feb 02 '23 at 18:38
  • 2
    Side note: There is also the nightmare case of a pointer pointing somewhere it shouldn't or a buffer overflow in some other part of the program stomping `h`'s storage. A breakpoint on memory change might be the best tool you have. – user4581301 Feb 02 '23 at 18:47
  • @Ash you can change the files, though maybe not in the VCS repository (though i somehow doubt you have one). anyway gdb should be able to debug such files. – Neil Butterworth Feb 02 '23 at 18:48
  • @user458 that is a good thought – Neil Butterworth Feb 02 '23 at 18:49
  • do [watchpoints](https://stackoverflow.com/questions/3099537/how-to-monitor-variables-in-gdb-and-log-it-if-it-meets-certain-conditions) solve your problem? it's like setting a breakpoint on the variable to break when the variable changes – user253751 Feb 02 '23 at 18:55
  • @user253751, no it didn't solve the problem. – Rebel Feb 02 '23 at 21:20
  • @user4581301, would you elaborate on your suggestions in the form of an answer? – Rebel Feb 02 '23 at 21:22
  • 2
    It'd be a carbon copy of [Can I set a breakpoint on 'memory access' in GDB?](https://stackoverflow.com/q/58851/4581301). Probably an inferior one. – user4581301 Feb 02 '23 at 21:24
  • 1
    In the general case, this is called *program slicing*, and was a research topic 20 to 30 years ago. In your specific case, where you only want to go back one step, you can do this by placing a breakpoint at the point where h is consumed, then placing a write watchpoint on h, then reversing execution until the watchpoint is hit. If you can provide a more concrete definition of *consumed*, we can show a sample GDB session. – Mark Plotnick Feb 03 '23 at 05:19
  • Thank you Mark, this is very helpful, I appreciate that, – Rebel Feb 03 '23 at 05:22

0 Answers0