msmithy12
Posts: 94
Joined: Fri Aug 10, 2012 8:57 am

Debugging on a Pi

Wed Aug 22, 2012 10:28 am

ok so im writing some very very basic c programs at the moment using 'nano' and 'gcc' trying to tech myself using FAQs forums and google searches and what i would ideally like do is watch the defined int/float and arrays as they are loaded with numbers and cleared. stepping the program line by line. Is there a program that will allow me to do that on the Pi itself? i have found links to DDD and GDB but am reluctant to install anything on my pi that could be too power hungry and fry my new toy.

Thanks in advance

pwinwood
Posts: 83
Joined: Mon Jul 02, 2012 2:21 am
Location: Oxford, England

Re: Debugging on a Pi

Wed Aug 22, 2012 10:39 am

There are no problems with using DDD or GDB on the Pi :D

LordSputnik
Posts: 17
Joined: Mon Jul 16, 2012 8:39 pm

Re: Debugging on a Pi

Wed Aug 22, 2012 11:15 am

You can also debug without any external tool - just do:

Code: Select all

#include <stdio.h> //If using C
#include <cstdio> //If using C++.

printf("My Float Value: %.2f\n",the_float);
printf("My Integer Value: %i\n",the_int);

unsigned int i = 0;
for(; i != ARRAY_SIZE; ++i)
{
 //Print value of array[i], as above.
}
At any points in the code you want to see the values.

P.S. I'd advise learning C++ rather than C if you have the choice. It's a more relevant language on modern machines, and everything you can do in C can be done in C++. Tutorial: http://cplusplus.com/doc/tutorial/

User avatar
hellonearthis
Posts: 22
Joined: Sun Aug 05, 2012 6:35 pm

Re: Debugging on a Pi

Wed Aug 22, 2012 11:26 am

For those wondering what GDB and DDD are, there are some links.

LordSputnik has the best approach to debugging, just dump the variables to display.

The Raspberry Pi has some JTAG support on the GPIO pins, if you need to step through what the CPU is doing for super serious debugging.

pjc123
Posts: 921
Joined: Thu Mar 29, 2012 3:37 pm
Contact: Website

Re: Debugging on a Pi

Wed Aug 22, 2012 11:46 am

Two ide's with debuggers for C that seem very popular and are included in the Debian repositories:

codelite for Debian Squeeze
code::blocks for Debian Wheezy

codelite seems to be the lighter of the two, but I have Wheezy, so I installed code::blocks. Although I haven't used it other than making sure it runs, code::blocks installed fine. Unless I come across a really bad obscure bug, I also just use vim and printf statements to see what is going on. You will not damage your pi because an ide uses too much resources, it will just run slow.
My Raspberry Pi Project Page:

https://www.flaminghellmet.com/launch/

MattOwnby
Posts: 58
Joined: Thu Aug 16, 2012 7:22 pm

Re: Debugging on a Pi

Wed Aug 29, 2012 9:33 pm

hellonearthis wrote: LordSputnik has the best approach to debugging, just dump the variables to display.
As a professional software developer (hehe), I discourage the use of print statements to debug. Sure, it is "quick n dirty" and might save you some time if you are writing a simple "hello world" program but once you get serious about writing software, you need to bite the bullet and learn "gdb". It's not nearly as nice to use as Visual Studio's debugger, but it is fairly powerful and there are frontends for it that make it a bit easier to use.

To get started with gdb,

gcc -g helloworld.c -o helloworld

gdb helloworld
break main
run

(execution stops on "main" function)

Some commands I always use:

next
(repeat, it steps through programs line by line)

step (steps into a function)

finish (steps out of a function)

continue
(resumes execution)

print yourvariablenamehere
(print a variable name)

x/10b somememorypointer
(examines the first 10 bytes of a memory pointer)

bt
(shows stack trace)

break main.c:50
(sets a breakpoint on line 50 of the main.c file)

break Yourclass::Yourmethod
(sets a breakpoint on the entrypoint of this method without needing to know the line number)

PaulBuxton
Posts: 57
Joined: Tue Jan 10, 2012 11:38 am

Re: Debugging on a Pi

Thu Aug 30, 2012 9:00 am

I would agree with Matt, if the tools are available then learn to use them, gdb used well can be very powerful.
In addition you can learn to code things in such a way that if your program fails, it should be able to give you a clue why. Testing assumptions about your code (e.g. checking parameters to sections of code) will allow you to narrow down the area in which to start looking for a problem the assert macro should be used to test for incorrect assumptions, so when you enter a function assert that the input pointers are not null before using them, or when iterating over the contents of an array, assert that the index you use is not >= the size of the array

The other way (and sometimes the only way) of debugging is to look through your code. Often explaining it to someone else will help you see where a problem lies, they don't even need to understand what you are saying as it the act of explaining that helps clarifies things in your mind.
Break the code up into small sections and step through it in your head, think about how the data will start out and finish for that section, and in what conditions it might fail, then move onto the next section.

One of my favourite parts of my job is debugging, it can be like a little puzzle and you get a nice sense of accomplishment when you solve a difficult one.

Paul

User avatar
Gert van Loo
Posts: 2487
Joined: Tue Aug 02, 2011 7:27 am
Contact: Website

Re: Debugging on a Pi

Sun Apr 06, 2014 12:54 pm

The one thing I use DDD and GDB for is to debug segmentation faults.
Often I run over the end of an array because I forgot something.
The whole problem is to find out WHERE in the program does it happen.
So just start gdb <program>
run
and get to the core dump.

99% of the time just looking at the code line where the error appears is enough to come to
DOH!

Shazaam_Glomutron
Posts: 4
Joined: Thu Aug 24, 2017 7:19 pm

Re: Debugging on a Pi

Tue Jan 23, 2018 10:32 pm

As a professional software developer, please avoid using "print" statements as your systemic debugging approach. Doing this ha few times for quick fixes is fine and probably expedient. Basing your debugging policy on this practice is dangerous for a number of reasons.
  • Turning off these print statements for a large codebase is time consuming and prone to human error
  • Deployed code shouldn't clutter the end user's screen with unnecessary debug statements that only mean something to you
  • Printing information to the screen is an EXTREMELY time consuming process and can slow your program down by anywhere from 2-100x, or more.
  • If you're including debug information for your client to use as a tool for reporting information back to the developer, then you should instead look at implementing a logging system which will write your debugging information to files, or packet streams, or whatever you prefer.
  • Logging systems also include a verbosity setting which will allow you, and the end user control over what they see.
  • If you must print to screen, consider writing your own separate window to print to, and send the debug information to that screen on a separate thread, so that it doesn't slow your main thread down with print statements.
Rant complete

User avatar
jahboater
Posts: 7150
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Debugging on a Pi

Tue Jan 23, 2018 11:42 pm

msmithy12 wrote:
Wed Aug 22, 2012 10:28 am
ok so im writing some very very basic c programs at the moment using 'nano' and 'gcc' trying to tech myself using FAQs forums and google searches and what i would ideally like do is watch the defined int/float and arrays as they are loaded with numbers and cleared. stepping the program line by line.
Is there a program that will allow me to do that on the Pi itself?
Yes GDB!!
msmithy12 wrote:
Wed Aug 22, 2012 10:28 am
i have found links to DDD and GDB but am reluctant to install anything on my pi that could be too power hungry and fry my new toy.
You will never ever fry a Pi just by running big programs. It is very robust. Physical abuse of the GPIO pins will hurt it, but thats something else.

Use GDB. You do not need to install it, its already included in Raspbian.
It is a very powerful debugger and works fine on the Pi.

There are other tools such as valgrind and the GCC sanitizers to help you find problems, but first concentrate on learning GDB. And again for emphasis, it is harmless, it wont hurt your Pi.

User avatar
bonzadog
Posts: 272
Joined: Wed Apr 25, 2012 9:40 am
Location: Rietberg/Germany

Re: Debugging on a Pi

Sat Feb 16, 2019 1:35 pm

Shazaam_Glomutron wrote:
Tue Jan 23, 2018 10:32 pm
As a professional software developer, please avoid using "print" statements as your systemic debugging approach. Doing this ha few times for quick fixes is fine and probably expedient. Basing your debugging policy on this practice is dangerous for a number of reasons.
  • Turning off these print statements for a large codebase is time consuming and prone to human error
  • Deployed code shouldn't clutter the end user's screen with unnecessary debug statements that only mean something to you
  • Printing information to the screen is an EXTREMELY time consuming process and can slow your program down by anywhere from 2-100x, or more.
  • If you're including debug information for your client to use as a tool for reporting information back to the developer, then you should instead look at implementing a logging system which will write your debugging information to files, or packet streams, or whatever you prefer.
  • Logging systems also include a verbosity setting which will allow you, and the end user control over what they see.
  • If you must print to screen, consider writing your own separate window to print to, and send the debug information to that screen on a separate thread, so that it doesn't slow your main thread down with print statements.
Rant complete
----------------------------------------------------------------------------------------------------------------------------------------------------

(British English)
Rant accepted! .
I entirely agree with you, but one could set a global flag that would enable such print commands.
if debug-flag
{
print info;
.......
}
Logging can cause space problems - I had that problem when I had to take over a colleague's programme - he had an inbuild logger set on.

User avatar
bonzadog
Posts: 272
Joined: Wed Apr 25, 2012 9:40 am
Location: Rietberg/Germany

Re: Debugging on a Pi

Sat Feb 16, 2019 1:38 pm

jahboater wrote:
Tue Jan 23, 2018 11:42 pm
msmithy12 wrote:
Wed Aug 22, 2012 10:28 am
ok so im writing some very very basic c programs at the moment using 'nano' and 'gcc' trying to tech myself using FAQs forums and google searches and what i would ideally like do is watch the defined int/float and arrays as they are loaded with numbers and cleared. stepping the program line by line.
Is there a program that will allow me to do that on the Pi itself?
Yes GDB!!
msmithy12 wrote:
Wed Aug 22, 2012 10:28 am
i have found links to DDD and GDB but am reluctant to install anything on my pi that could be too power hungry and fry my new toy.
You will never ever fry a Pi just by running big programs. It is very robust. Physical abuse of the GPIO pins will hurt it, but thats something else.

Use GDB. You do not need to install it, its already included in Raspbian.
It is a very powerful debugger and works fine on the Pi.

There are other tools such as valgrind and the GCC sanitizers to help you find problems, but first concentrate on learning GDB. And again for emphasis, it is harmless, it wont hurt your Pi.
One can use a tool called visualdbg. One can use MS VS to write and test C/C++ programmes on the RPi and other HW
CAVEAT: It cost a bit.
https://visualgdb.com/

swampdog
Posts: 718
Joined: Fri Dec 04, 2015 11:22 am

Re: Debugging on a Pi

Sat Feb 23, 2019 1:45 am

In case nobody knows you can turn on core dumps which can be a much faster way to get to the problem.

$ cat c.cc

Code: Select all

#include <iostream>

using namespace std;

void foo ()
{
 char *p=0;
 *p=-99;
}

main()
{
 foo(); 
 return 0;
}

Code: Select all

$ ulimit -a
$ ulimit -c unlimited
$ gcc -o c -g c.cc
$ ./c
Segmentation fault (core dumped)
$ gdb c -c core
(gdb) bt
(gdb print p
(gdb) q
$ rm -v core
The reason it's off by default is core files can be large and end up scattered all over the place if enabled globally (which used to be the case).

User avatar
bonzadog
Posts: 272
Joined: Wed Apr 25, 2012 9:40 am
Location: Rietberg/Germany

Re: Debugging on a Pi

Sat Feb 23, 2019 6:05 am

bonzadog wrote:
Sat Feb 16, 2019 1:35 pm
Shazaam_Glomutron wrote:
Tue Jan 23, 2018 10:32 pm
As a professional software developer, please avoid using "print" statements as your systemic debugging approach. Doing this ha few times for quick fixes is fine and probably expedient. Basing your debugging policy on this practice is dangerous for a number of reasons.
  • Turning off these print statements for a large codebase is time consuming and prone to human error
  • Deployed code shouldn't clutter the end user's screen with unnecessary debug statements that only mean something to you
  • Printing information to the screen is an EXTREMELY time consuming process and can slow your program down by anywhere from 2-100x, or more.
  • If you're including debug information for your client to use as a tool for reporting information back to the developer, then you should instead look at implementing a logging system which will write your debugging information to files, or packet streams, or whatever you prefer.
  • Logging systems also include a verbosity setting which will allow you, and the end user control over what they see.
  • If you must print to screen, consider writing your own separate window to print to, and send the debug information to that screen on a separate thread, so that it doesn't slow your main thread down with print statements.
Rant complete
----------------------------------------------------------------------------------------------------------------------------------------------------

(British English)
Rant accepted! .
I entirely agree with you, but one could set a global flag that would enable such print commands.
ERRATA:
get the flag from the line command
and set debug-flag as either true or false -- this stops compiling every time the flag is set/unset
(valid for any language)

if debug-flag
{
print info;
.......
}
Logging can cause sp
ace problems - I had that problem when I had to take over a colleague's programme - he had an inbuild logger set on.

Brian Beuken
Posts: 374
Joined: Fri Jan 29, 2016 12:51 pm

Re: Debugging on a Pi

Tue Feb 26, 2019 12:30 pm

Rant is very valid, but when teaching total beginners, especially those who do not yet demonstrate an aptitude for coding and are very easily deflated, I honestly think that its important to avoid any complications in what you are explaining.
The word print just makes sense to new coders. I've seen new programmers get utterly thrown just by seeing a printf in the mix...why is there an f....its confusing, what does it mean! etc!

Early projects from beginners are never going to form the code base of a serious project so letting them fill it with easy to understand prints that make sense, keeps them aware of the flow of the program. They can learn to use conditional logging systems once they get their heads around the basics.

Let new coders do what works and is easy to understand, we can impose standards and rules on them when they get beyond the point where every instruction is to be feared in case it blows up the internet!
Last edited by Brian Beuken on Wed Feb 27, 2019 12:59 am, edited 1 time in total.
Very old computer game programmer, now teaching very young computer game programmers, some very bad habits.
http://www.scratchpadgames.net/
https://www.patreon.com/BrianBeuken

aLotOfSensor
Posts: 11
Joined: Sun Sep 16, 2018 5:14 pm

Re: Debugging on a Pi

Tue Feb 26, 2019 7:42 pm

msmithy12 wrote:
Wed Aug 22, 2012 10:28 am
ok so im writing some very very basic c programs at the moment using 'nano' and 'gcc' trying to tech myself using FAQs forums and google searches and what i would ideally like do is watch the defined int/float and arrays as they are loaded with numbers and cleared. stepping the program line by line. Is there a program that will allow me to do that on the Pi itself? i have found links to DDD and GDB but am reluctant to install anything on my pi that could be too power hungry and fry my new toy.

Thanks in advance
The closest you will find to that on linux is - https://github.com/eteran/edb-debugger - but it's for x86/x64 and it's pretty unstable. I used to use it before I learned gdb. Yeah, gdb isn't convenient.

If static analysis would suit you IDA is probably the only stable GUI debugger you will find for x86/x64/arm linux, but it's static so you won't see dynamic changes like you're talking about. It's really easy to use though.
what i would ideally like do is watch the defined int/float and arrays as they are loaded with numbers and cleared
This part isn't really that hard, this is just a hex/memory dump reading from process memory via ptrace(), or something just iterating over address spaces from inside the process. This would be the "data dump" section on edb, the lower left corner.
stepping the program line by line
This is the hard part, because now you have to get something to visualize all the registers, the binary instructions, the asm mnemonics, etc. Ollydbg on windows is the only debugger I know of, that ever got this right. And it's x86 only. There have been many projects that tried to replicate Olly's interface for other platforms and at best they turned out to be half working, unstable softwares like x64dbg, edb, etc. So unfortunately I think this will be very difficult to find, but awesome if it's out there.

User avatar
jahboater
Posts: 7150
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Debugging on a Pi

Tue Feb 26, 2019 7:58 pm

aLotOfSensor wrote:
Tue Feb 26, 2019 7:42 pm
stepping the program line by line
This is the hard part, because now you have to get something to visualize all the registers, the binary instructions, the asm mnemonics, etc.
This is easy on the Pi.
Start the debugger as usual.
type:

Code: Select all

layout reg
The debugger will go full screen with three windows:-
1) The registers and their values (the last changed registers are highlighted).
2) The assembler instructions with the current instruction arrowed and highlighted.
3) The command window where you type debugger commands

Set a breakpoint and run the program in the usual way.

Use "si" or "ni" to step through instruction by instruction, watching the registers change.

Pressing <return> always executes the last instruction.

See also "tui reg float"

aLotOfSensor
Posts: 11
Joined: Sun Sep 16, 2018 5:14 pm

Re: Debugging on a Pi

Tue Feb 26, 2019 10:15 pm

Hi jahboater,

Yes gdb has tui mode and layout reg but it's still a pain in the @ss to use that when spending hours at a time in front of a debugger. That's not really a GUI either, it's still a CLI, kind of like a glorified objdump CLI interface.

What I was referring to, and what I think OP is referring to, is Ollydbg style interfaces, the software that edb was modeled after. A complete GUI (ie it uses a GUI lib, be it gtk, qt, win32api, etc) interface with data visualization conveniences like ASM mnemonic highlighting, register vs mem address vs pointer vs etc highlighting, JMP instruction line drawings to visualize code execution flow, etc - and most importantly point and click convenience so I don't have to touch the keyboard. Clicking is a lot faster than typing. Don't get me wrong, gdb is better than nothing - but it does none of what I've described. If I want to step through 100K instructions to replicate a closed source driver in C or track down a bug, pointing & clicking is 1000x faster than typing debugger commands like you describe.

This type of software is very, very difficult to implement though. Many have tried. I'm sure there are private, in house tools that do this for very well funded teams but at least now nothing public.

User avatar
jahboater
Posts: 7150
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Debugging on a Pi

Wed Feb 27, 2019 3:04 am

aLotOfSensor wrote:
Tue Feb 26, 2019 10:15 pm
Yes gdb has tui mode and layout reg but it's still a pain in the @ss to use that when spending hours at a time in front of a debugger. That's not really a GUI either, it's still a CLI, kind of like a glorified objdump CLI interface.
It is ncurses screen output, which has the advantage that it works in a terminal window.
This is useful for headless servers, here running Raspbian Lite.

Return to “C/C++”