C: freedom from PICs

[brucehoult]

I never use a debugger. Not on the desktop, not in embedded.
I write temporary code (as described above) that outputs debugging info to the console, a serial port or a file.
It saves a lot of time.

That simply means you have never done any serious software work.

Lol.

Literally.

[brucehoult]

When learning C (or C++) I would consider it to be mandatory to have a working Debugger. Settings breakpoints, stepping though the code and inspecting variables during execution is a great learning tool.

I completely disagree!

That was valuable back when recompiling your program took minutes or even hours.

However trying to visually parse the information you want out of debugger output is slow and tiring, and inserting debugger actions at breakpoints using a language that is not quite the same as the language your program is in is both annoying and slows the execution of your program a lot.

Far better in these days of less than 1 second program builds to do add your temporary debugging code (including any conditional tests) right in the program itself, and use printf or cout to print precisely the information you actually want in exactly the format you want. Send the output to less or to a log file and use your favorite editor or grep or less or perl or whetever you want to search for interesting things in the log.

When finished you can delete the debugging code or else add #IFs to disable it and easily use it again at some later date if you need it.

See my response above.

1 second builds do not happen with complex projects.

Adding debug code to a timing and resource tight embedded application  (what is called "intrusive debugging") is simply not possible in many complex applications. That is what uneducated arduino folks do, because they don't know any better (and even can't learn any better because people who think like you) . And that is where a skilled software engineer brings up his box of tools for non-intrusive debugging.

Lol again.

I'm pretty sure Nominal Animal, NorthGuy, westfw, to name just a few (in alphabetical order), are highly skilled software engineers. They also happen to be expressing the same views as I am.

[Siwastaja]

The idea that a debugger is somehow magically non-intrusive is blatantly false.

Quite the opposite, the typical usage of debuggers, including breakpoints, single stepping, and memory view which is based on actual bus operations instead of a separate trace interface, is massively intrusive.

Almost all debugging is intrusive; you need to understand how much, and where, and how to cope.

[SiliconWizard]

The idea that a debugger is somehow magically non-intrusive is blatantly false.

Quite the opposite, the typical usage of debuggers, including breakpoints, single stepping, and memory view which is based on actual bus operations instead of a separate trace interface, is massively intrusive.

Almost all debugging is intrusive; you need to understand how much, and where, and how to cope.

Yes, of course. This is especially true when using them on embedded targets, but even with "desktop" programming, particularly as soon as you debug multi-threaded stuff, debugging can be full of suprises.

Another common point related to debuggers is that you may encounter bugs that only manifest themselves (or at least than you can only reproduce) when the code is compiled with optimizations. But optimized code is notoriously hard to debug through a debugger. Sometimes you then have to step through assembly, which can be very tedious and hard to link to the actual source code.

When you mix both aspects, the above example of using debuggers on DSPs running a lot of concurrent stuff (such as DMA) is not necessarily the best, and certainly not the easiest. You really need to know the limitations of debuggers, what you are doing and what you're looking for.

As with any other tools, debuggers have their uses, but you really need to know their limitations and how to use them properly. They are also generally not the first thing to use when trying to track a problem down or just trace code execution. As mentioned above, "manually" sending out debug messages in your code, as "old tech" as it may look to some, is often the most sensible thing to do. If done right, you can completely predict how this will impact code execution, and you can also trace long sequences of events, which is a time saver compared to manual stepping using a debugger. IME, debuggers have now become the last resort in very particular cases, not the first thing I fire up.

Now if we get back to the topic itself - and I guess the use case is starting to write simple C programs on desktop OSs - some people may use, or suggest to use a debugger as a means of understanding how code executes, and as a long as said programs are single-threaded, don't use any fancy OS asynchronous calls, etc, I guess there are few traps to be aware of then. But still, the matter of debugging optimized code may surprise some people, and the fact that optimized code may not behave like non-optimized code as well. This would be an opportunity to see for yourself, though.

[Yansi]

The idea that a debugger is somehow magically non-intrusive is blatantly false.

Quite the opposite, the typical usage of debuggers, including breakpoints, single stepping, and memory view which is based on actual bus operations instead of a separate trace interface, is massively intrusive.

Almost all debugging is intrusive; you need to understand how much, and where, and how to cope.

Sure, so massively intrusive, that your PRINTF through UART is somehow good approach, especially for a resource-limited embedded target, such as the stupid *duino.

Tell that to someone else.

[Nominal Animal]

It is not the debugger nor the method of debugging that matters as much as obtaining the pertinent information and understanding what is happening, that matters.

My favourite example of this is when you have a linked list, tree, or graph, and something goes b0rk.

If you reach for a debugger first, I feel for you.  Sure, debuggers like gdb nowadays are quite extensible, so you can teach them about your data structures so you can query the application state quite effectively, but it is a lot of detective work to find out what exactly did go b0rk with a debugger.

What I do, is have a function emit the structure description in Graphviz dot language to a file, and visualize that.  For example, if I have a binary search tree,

Code: [Select]

struct node {
    struct node *le;
    struct node *gt;
    /* Some payload, say a string: */
    char *data;
};
I habitually write a debugging function for it, something along the lines of

Code: [Select]

static void debug_tree_node(FILE *out, const struct node *node)
{
    fprintf(out, "  \"%p\" [ label = \"%s\" ];\n", node, node->data);
    if (node->le) {
        debug_tree_node(file, node->le);
        fprintf(out, "  \"%p\" -> \"%p\" [ taillabel = \"<=\" ];\n", node, node->le);
    }
    if (node->gt) {
        debug_tree_node(file, node->gt);
        fprintf(out, " \"%p\" -> \"%p\" [ taillabel = \">\" ];\n", node, node->gt);
    }
}
void debug_tree(FILE *out, const struct node *tree)
{
    fprintf(out, "digraph {\n");
    if (tree) debug_tree_node(out, tree);
    fprintf(out, "}\n");
}

While this is obviously a form of "printf debugging", displaying the generated dot graph description via dot -Tx11 output is absolutely indispensable in understanding how things went b0rk, so that one can start finding out why.

(For learners, I actually prefer a more complicated version, that tracks nodes either via a dedicated "visited" field in the structure, or by putting the node addresses in a hash table.  That way the debugging output won't get dazed and confused by cyclic graphs and such.)

When a student sees the (incorrect) tree/graph their code generates, in my experience they are more likely to understand what they did wrong.
The key, of course, is to first understand the b0rk first.  And for that, I claim it does not matter what debugging tool you use, as long as you are efficient about it.

The point where I fire up my debugger, is when I need to know what is happening at the machine code level.  Usually, when I just want to track certain variables etc. in real time in a multithreaded process, I use a dedicated thread to "printf-debug" their changes.  In a couple of cases, I've written my own "debugger" using the ptrace interface, to ensure minimal interference with the target process (Heisenbugs, 'nuf said).  See e.g. here for an example one for multithreaded processes I wrote in 2013.

It is perfectly okay if you disagree, but for me, these patterns have proven their worth in real life, both for myself, and as an educational tool, helping others learn.  I'm not writing this to change anyones mind, but to explain the practical reason and experience behind my opinion.

[Siwastaja]

Sure, so massively intrusive, that your PRINTF through UART is somehow good approach, especially for a resource-limited embedded target, such as the stupid *duino.

Obviously, do not just sprinkle printf in random places. That's a complete strawman. Similar strawman would be saying that the only thing you can do in a debugger is to single-step code.

[neil555]

PellesC for windows is a good free compiler and has an IDE and debugger ...

http://www.smorgasbordet.com/pellesc/