How to debug?
-
Preferably C, although I could live with Python, I suppose
-
@mawg I'm not clear on what you are developing and the debugging method is often different depending on what you are developing and precisely where your code runs. Is it a kernel level driver or a loadable module or just a user app?
-
I haven't tried to run GDB on the onion, although GDB is probably what you want to use for debugging the sort of software that runs above an OS (i.e. OpenWRT Linux).
https://openwrt.org/docs/guide-developer/gdb?s[]=gdb
I don't believe the Onion has an exposed JTAG interface. Nor would you really want to use it unless you were debugging the bootloader and/or kernel themselves.
-
@mawg If you are developing a user space app, I recommend getting good at using logging to troubleshoot your app. Later when your app is in production using GDB is often not an option but if you have coded some good logging into your app you only need to turn it on to troubleshoot. Take a look at how you can use remote logging with the Omega, https://community.onion.io/topic/3649/enabling-netconsole/4
I can troubleshoot devices using my apps anywhere in the world simply by turning on logging and the logs come right to my door in real time.
I believe GDB has it's place but it should be a last resort.
If you are developing lower level code for kernel modules etc you'd need to use GDB.
-
Why would GDB be a last resort? Obviously, you would use it with a debug build. It will show thread calls and allow trace-back to the point of any crashes. If you're programming in C, that's helpful.
Anyway, here's how I write C programs for Linux. Most of which are multithreaded, via pthreads, and many of which access devices.
-
Set up an environment on mac using the libraries you'll need, but for the mac platform. Mac uses the XNU kernel, which is based on BSD, and it's far more reliable than most linuxes. Controversial, yes, but from my experience very true. Especially for multithreaded apps.
-
Code the software in XCode. XCode has the best linting and real-time error/warning detection of any tool I've ever seen. It runs LLVM/Clang underneath, which is has a compatible interface with GCC. You'll detect most bugs before you even build your app.
-
Run the software on mac. You can use lldb or gdb (I use both). lldb is somewhat more capable IMO.
-
Once it works on mac, get it running on a Linux desktop. Use GDB for debugging.
-
Once it works on Linux desktop, get it running on the Linux target platform (i.e. Onion). A nice I/O-driven test framework for this purpose is TAP (Test Anything Protocol).
-
-
@JP-Norair It's kind of off topic, so I won't give a detailed response other than to say I find this approach awfully repetative. I started coding before we had integrated debuggers and it makes me chuckle when I see developers unable to manage without them.
-
Do you chuckle at people using electric and pneumatic tools to build things? We have these tools now, so you probably should use them. I don't suspect anyone is "unable to manage without [GDB]," but it makes the job a whole lot easier.
As for my development methodology, most-often the huge majority of time is spent on the mac, and it's much faster to iterate on a desktop than it is on an embedded target. One example of a problem appearing in a late stage of this process is my recent struggle with the tty driver on the Omega2, which wasn't obvious until running on the omega2, but this wouldn't have been any easier to deal-with had I been running directly on the target the whole time. There's simply a bug in musl.
Anyway, the theme is pretty simple: the best strategy is the one that yields the best result in the shortest time.
-
@crispyoz just a user app
-
@mawg depending on the complexity of your code I find remote logging is simpler, for reasons I explained above. @JP-Norair has a different view and I don't entirey disagree with him, but sometimes the simpler solution is a better fit. You'll need to make your own judgement as to what fits you best.
-
@crispyoz Sorry, but I have been a professional developer for 40 years now and cannot live without a debugger.
Does the Omega (2) have onboard debugginf software? Failing that is there any JTAG? My software is of a complexity that I need to be able to set beakpoints, examine the stack & variables, etce, etc. "debug by printf()" just won't cut it for me.
I would prefer to code in Ada, but doub that that will be possible; failing that, C; failing that Python.
Should I seek a different platform?
-
@mawg You should see if it's possible to run GDB on your onion -- probably you'll want the Omega2 that has the most RAM, i.e. 2+. GDB offers things like breakpoints, stack-trace, read variables, capture on fault, etc.
https://docs.onion.io/omega2-docs/c-compiler-on-omega.html
Midway down this page, there's description on how to install gdb.