0

I have a script which debugs my application and it does set 2 breakpoints. If I would be debugging it manually I would be able to see which one got triggered. But doing it in an automatic manner, I don't know which breakpoint was reached, is there a way to write if conditions or something to detect which one was reached?

If this feature is not possible with vanilla gdb but only with python gdb I would be happy to switch/upgrade the process.

Edit: With Tom's help I can have

break main
commands
  set $gdb_breakpoint=1
end

break main.cpp:4053
commands
  set $gdb_breakpoint=2
end

break fault_handler.cpp:55
commands
  set $gdb_breakpoint=3
end

break unit_tests_complete
commands
  set $gdb_breakpoint=4
end

And then when the breakpoints got triggered I can check the variable to know where I got halted. In a pure software context this could be easier and maybe multiple breakpoints wouldn't be needed to begin with. This is testing hardware where the fault could happen erratically then this approach should do the trick.

Anton Krug
  • 1,555
  • 2
  • 19
  • 32
  • Very absurd observation, I have breakpoints set within a define function together with the "commands", when the "continue" command is called from within a define function it will not trigger commands, but calling the "continue" from top is still fine. Not sure if this would justify separate SO thread question. – Anton Krug Aug 17 '18 at 10:44

1 Answers1

2

The gdb CLI provides a commands command which can be used to attach other gdb commands to a breakpoint. So for example:

(gdb) break main
Breakpoint 1 at 0x40ce90: file ../../binutils-gdb/gdb/gdb.c, line 25.
(gdb) commands 1
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>print "hi"
>end

... will arrange to print "hi" when the breakpoint is hit.

If you prefer to use Python, then you can add a listener to the gdb.events.stop event, and look specifically for breakpoint stops.

Tom Tromey
  • 21,507
  • 2
  • 45
  • 63
  • I do not prefer Python as I'm trying to make this work as compatible as possible and If I can get this working without Python dependance then I'm going for it. Sadly more and more limitations show up with vanilla gdb which is no problem with Python so trying to avoid it might be futile. I really appreciate you gave me answers for both. – Anton Krug Aug 16 '18 at 10:09
  • 1
    Yeah, gdb's CLI scripting language is pretty limited. You can do a surprising amount with it, but there are some times when the Python interface is the only way. – Tom Tromey Aug 16 '18 at 13:44
  • yes exactly, before I didn't even had an option of python and was surprised it can do still plenty even when a lot of stuff is Python only feature, one I miss the most is able to make if conditions on host's environment variable. So I now I made workarounds for vanilla gdb so I will keep going until it will not be possible and then probably rewrite everything into python. Which should give enough time to the users, when they will be told to install python now as the scripts at some point will need it. – Anton Krug Aug 16 '18 at 14:19