1

I’d like to be able to write annotations for GDB breakpoints directly into my C-source.

Instead of having to go into the GDB tui and add breakpoints using line numbers, function names, regex, etc., I want a build pipeline that enables add comment (or similar) in C code -> get breakpoint in GDB.

In case it might help to clarify, I’m currently thinking of enabling something like this:

foo();
bar(); // #breakpoint
baz();

I’d write a bash script, cbreak, that checks all lines of all the .c files in a directory for that #breakpoint annotation, and outputs each one that has the annotation to a file break.br.

I can then cbreak && gcc … && … and load the breakpoints from break.br.

Is there a tool that already exists for this? Is this a bad idea?

lmonninger
  • 831
  • 3
  • 13
  • 2
    What problem are you trying to solve? http://xyproblem.info may be relevant here. – Employed Russian Nov 08 '22 at 00:30
  • 3
    Change `// # breakpoint` to `MyBreakPoint();` (maybe before the statement you want to break at instead of after it), declare and define `void MyBreakPoint(void) {}`, and, in the debugger set a breakpoint on `MyBreakPoint`. – Eric Postpischil Nov 08 '22 at 00:39
  • 1
    I agree it’s not well formed. The problem is, in short: how do I create breakpoints in GDB from annotations in C source? However, because I believe I know at least one way to do this, I’m not interested in another bash script. I’d want to know if there is an established way of achieving this via, for example, some build tool. – lmonninger Nov 08 '22 at 00:44
  • 1
    @EricPostpischil But, that means I still have to manually set the breakpoint haha. Let me reword my question. – lmonninger Nov 08 '22 at 00:44
  • 2
    @lmonninger: You can set the breakpoint in the gdb startup file. – Eric Postpischil Nov 08 '22 at 00:47
  • @EricPostpischil Sweet! Yeah, I’ve thought that might be the better way to do the second half of the problem, i.e. loading the breakpoints as painlessly as possible. I was wondering if that would get annoying or clumsy in case I want to abandon the breakpoints quickly or use different breakpoint configs. Is there a way to include other .gdbinit -like files in .gdbinit? – lmonninger Nov 08 '22 at 00:54
  • 1
    You can `source` a [command file](https://sourceware.org/gdb/onlinedocs/gdb/Command-Files.html#Command-Files) in the startup file or at any other time. – Hasturkun Nov 08 '22 at 01:21
  • @Hasturkun Perfect. If there isn’t already a separate q on SO for that inclusion, I’ll add one and tag you. – lmonninger Nov 08 '22 at 01:27
  • 1
    Isn't gdb scriptable with guile or python or something? – Shawn Nov 08 '22 at 02:08
  • Why do you want to annotate _the sources_ of the code to debug at the first place? This will trigger a rebuild each time you change your list of breakpoints, which I would avoid to some extend as it changes the unit under test. (This is another hint that this is a XY problem.) – the busybee Nov 08 '22 at 07:17
  • 2
    Maybe you want to set breakpoints programmatically like this https://stackoverflow.com/q/4326414/72178 ? – ks1322 Nov 08 '22 at 09:49
  • @thebusybee there’s no Y. And, if I want to add more breakpoints on the fly, that’s not an issue. – lmonninger Nov 08 '22 at 10:03
  • @ks1322 I think yours is the way this should actually be done. – lmonninger Nov 08 '22 at 10:13
  • So it seems that you are not using a serious IDE, which allows you to set up breakpoints directly in the editor views. And perhaps you're a lonesome single developer and/or not using a revision control system, because potential team members would not want your breakpoints replacing theirs. – the busybee Nov 08 '22 at 11:07
  • @thebusybee It is a valid point. If you wanted to represent the breakpoints in source and automatically keep it clean for version control, you would want to introduce something like a cbreak profile. But, otherwise, yes, IDE. To clarify the context in which the question is asked, (a) there isn't a specific project for which this is desired, I just wanted to give it a try; (b) I only like to use IDEs when I absolutely must; and (c) I generally don't keep debugging logic in code that is pushed to any collaborative remotes nor do I believe that's necessarily an unreasonable standard for others. – lmonninger Nov 08 '22 at 17:30
  • 1
    Understood. Actually, I'm using Geany or other common editors for small experiments, mostly because of the overhead a "real" project needs in most IDEs. However, getting used to this habit is running in the wrong direction, in my view. But it's your project, and your development process. Good luck! -- Oh, and another thought: I hardly need to run my code in a debugger, `printf()`-debugging (see above, experiments...) or unit-tests are easier. – the busybee Nov 08 '22 at 17:37

0 Answers0