3 ms·

It makes me sad to hear people say things like this. Did you debug GDB to see why it was crashing?

by db48x 6y ago

rcxdude 6y ago
The saddest command I've ever typed was 'gdb gdb qtcreator', where inside qtcreator I was trying to debug using gdb. qtcreator was crashing when I tried to do that, and gdb was crashing when I tried to debug qtcreator crashing, and eventually I located a bug in gdb (which it turned out had been patched in a later version). It was a massive waste of my time and way off into yak shaving territory that I should have abandoned long before. Embedded debugging is a pile of woe as well, in my experience. On the current system I'm working on, with 4 different chips using 2 different architectures, 3-4 different JTAG adaptors and different vendors gdb integrations, none of the debugging interfaces work reliably. If you can get the software to start running under the debugger, usually the first breakpoint will get hit correctly. If you're lucky it'll even continue running after you restart it from that breakpoint. The next breakpoint is even less likely to work, let along actually being able to trace out the path of some code. In theory on one of the architectures the interface understands freertos threads, but that just reduces the odds of a successfull breakpoint even lower (and you can forget about support on the other ones).
- db48x 6y ago
  > It was a massive waste of my time and way off into yak shaving territory that I should have abandoned long before. I don’t know if I agree with you there. I suppose you did waste your time, since the bug turned out to already be fixed, but every crash has to be investigated by somebody. Otherwise, the wouldn’t get fixed. If they don’t get fixed, they simply waste everyone’s time, over and over again. The sad statement above was that the commenter saw a crash in a tool, and gave up instead of investigating. Thank you for not giving up when you were in the same situation! > Embedded debugging is a pile of woe as well I’ve never done anything of note on embedded platforms, but it certainly sounds like it. You would think that you could pay the vendors for better tools, but it sounds like they all just do the bare minimum, or they just do the bare minimum for anyone who doesn’t pay through the nose.
thrwaeasddsaf 6y ago
I didn't. I've a hunch that it's a very deep rabbit hole, which means understanding and fixing those crashes is going to be a significant time investment. I can't bill a customer for that time, and my boss won't be able to pay my salary if I spend weeks studying and fixing broken old debuggers instead of doing the work a customer pays for. Either way, the debugging experience without something like rr sucks hard when it comes to heavily multi-threaded, asynchronous, event-driven systems. So even if gdb didn't crash, its usefulness is very limited compared to simple tracing.

It makes me sad to hear people say things like this. Did you debug GDB to see why it was crashing?

by db48x 6y ago

It makes me sad to hear people say things like this. Did you debug GDB to see why it was crashing?

The saddest command I've ever typed was 'gdb gdb qtcreator', where inside qtcreator I was trying to debug using gdb. qtcreator was crashing when I tried to do that, and gdb was crashing when I tried to debug qtcreator crashing, and eventually I located a bug in gdb (which it turned out had been patched in a later version). It was a massive waste of my time and way off into yak shaving territory that I should have abandoned long before. Embedded debugging is a pile of woe as well, in my experience. On the current system I'm working on, with 4 different chips using 2 different architectures, 3-4 different JTAG adaptors and different vendors gdb integrations, none of the debugging interfaces work reliably. If you can get the software to start running under the debugger, usually the first breakpoint will get hit correctly. If you're lucky it'll even continue running after you restart it from that breakpoint. The next breakpoint is even less likely to work, let along actually being able to trace out the path of some code. In theory on one of the architectures the interface understands freertos threads, but that just reduces the odds of a successfull breakpoint even lower (and you can forget about support on the other ones).

db48x 6y ago
> It was a massive waste of my time and way off into yak shaving territory that I should have abandoned long before. I don’t know if I agree with you there. I suppose you did waste your time, since the bug turned out to already be fixed, but every crash has to be investigated by somebody. Otherwise, the wouldn’t get fixed. If they don’t get fixed, they simply waste everyone’s time, over and over again. The sad statement above was that the commenter saw a crash in a tool, and gave up instead of investigating. Thank you for not giving up when you were in the same situation! > Embedded debugging is a pile of woe as well I’ve never done anything of note on embedded platforms, but it certainly sounds like it. You would think that you could pay the vendors for better tools, but it sounds like they all just do the bare minimum, or they just do the bare minimum for anyone who doesn’t pay through the nose.

thrwaeasddsaf 6y ago

I didn't. I've a hunch that it's a very deep rabbit hole, which means understanding and fixing those crashes is going to be a significant time investment. I can't bill a customer for that time, and my boss won't be able to pay my salary if I spend weeks studying and fixing broken old debuggers instead of doing the work a customer pays for. Either way, the debugging experience without something like rr sucks hard when it comes to heavily multi-threaded, asynchronous, event-driven systems. So even if gdb didn't crash, its usefulness is very limited compared to simple tracing.