• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Development environment

ronaldlees

Aspiring Daemon

Thanks: 241
Best answers: 2
Messages: 631

#4
Can anyone suggest an Integrated Development Environment for FreeBSD where you can single step through a program, set breakpoints, etc ?

I am aware of https://www.freebsd.org/ports/devel.html but would prefer some recommendations for use with 'C'....
If you do not want to install or you don't need a glitzy GUI styled IDE or Emacs (actually a pretty friendly environment written by Richard Stallman), you can use vim or you can simply use the built-in debugging UI of GDB, by executing gdb with the “-tui” option:

visop5-s.png

Here it's shown debugging a simple OS kernel from Visopsys.org. The advantage of using the bare gdb debugger is that it will teach you the basics of debugging, without a fancy front-end GUI that may shield details that could help deeper understanding. Emacs works via direct interaction with the debugger as well. Maybe that combo could be a sort of intermediate step to get you going, since it's a very simple command line startup. Instant gratification, and not much prior knowledge needed.

I kinda like emacs for small projects (grin). Here's what tha man has to say about it:

 
Last edited:

kpedersen

Daemon

Thanks: 277
Messages: 1,086

#5
(Quite an old post but...)
If you are just starting out with development, then codeblocks is great. However if you are looking at honing your skills professionally, then IDEs are simply too inflexible and the better developers that I have worked with avoid them.

Perhaps try the following instead:

1) clang (C Compiler) or clang++ (C++ compiler)
2) gedit (simple text editor) or vim, emacs (more advanced text editors)
3) gdb, (Debugger so you can set breakpoints, step through the program)

One of the main reasons why IDEs are limited is because they don't well integrate the following important tools:

cmake (cross platform build system. Visual Studio .sln or code::blocks .proj files are not often used by other developers)
valgrind (runtime memory checker)
splint (static analysis)
doxygen (generating callgraphs / reverse callgraphs is very important for large teams)
jenkins / hudson (Build systems work with the command line. They often have very limited support for IDEs)
git / svn (version control support is always lacking in IDEs because the proj files or settings files do not merge well).
 

fnoyanisi

Active Member

Thanks: 97
Messages: 214

#7
This is one thing I am missing as well....CodeBlock was "okay" but the port has been broken for a while...
I may give a go to editors/codelite, seems like the best bid I (we) have... I have never been a java/eclipse fan to be honest, hence do nto want to go down the Eclipse + CDT track.

The main thing I am looking is a decent integration with gdb.

PS : Lately, I have done some iOS development, hence used Xcode and I think it rocks...
 

ShelLuser

Daemon

Thanks: 1,097
Best answers: 2
Messages: 2,424

#8
I'm a big fan of java/netbeans but as its location implies that's mostly because of my Java development. However, Netbeans also supports C/C++ these days and to my understanding also has excellent debugging support (including step traces). Unfortunately I program more with Java than C/C++ so I can't share hands on experience.
 

balanga

Daemon

Thanks: 59
Messages: 1,961

#9
The reason I wanted to set up a development environment where I could single step through code was to find out why kwboot would not work properly on FreeBSD. I download the source and it compiled but just wouldn't work...

See Thread 61777
 

aragats

Aspiring Daemon

Thanks: 339
Messages: 854

#10
The reason I wanted to set up a development environment where I could single step through code...
An IDE doesn't do any magic. So, the topic looks to be an XY problem.
That program sends data to a serial port, did you check the other end?
Also, you mentioned adding printf's, did you get any result?
(Sorry, these questions should go to another thread you mentioned)
 

balanga

Daemon

Thanks: 59
Messages: 1,961

#11
With an IDE I should be able to set breakpoints and view variables, but programming serial ports is a bit out of my league. I couldn't see any outputs from any printf's but maybe I couldn't figure out where code:blocks shows outputs. Maybe I'll try using gdb...
 

unitrunker

Member

Thanks: 26
Messages: 44

#12
Code blocks opens a separate window for your stdout.

One IDE not yet mentioned is JuCi++. It uses CMake as its build system.

Pros: Well integrated with clang. Where Code Blocks would display some obscure STL template header file while single-stepping the debugger (currently it only knows GDB even when compiling with clang/clang++), JuCi shows me the actual source location in my code. Auto-complete in JuCi makes editing a CMakeLists.txt file much easier.

Cons: UI in JuCi is very barren. A few commands (like clean / rebuild-all or closing out a project), are either not there or not obvious.

Thanks to JuCi, I don't hate on CMake as much as I once did.

> pkg install juci
 

kpedersen

Daemon

Thanks: 277
Messages: 1,086

#14
balanga, You don't need an IDE or a UI to use a debugger.

Make sure you compile your application with debugging symbols '-g'

Code:
$ clang -g *.c -o debug_program
Now if you run your program via gdb (or lldb as mentioned by Eric). Then execute "r" (for run).

Code:
$ gdb ./debug_program
> r
Then when it crashes, you can see the stacktrace by typing "where" and pressing enter.

A very simplistic flow of using gdb but you can also add watchers to variables and put breakpoints on line numbers. Perhaps have a quick read through some gdb tutorials.
 

balanga

Daemon

Thanks: 59
Messages: 1,961

#15
I kinda like emacs for small projects (grin).
Code:
root@Test:~/Desktop # pkg install emacs
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'emacs' have been found in the repositories
root@Test:~/Desktop #
???????
 

balanga

Daemon

Thanks: 59
Messages: 1,961

#16
Then when it crashes, you can see the stacktrace by typing "where" and pressing enter.

A very simplistic flow of using gdb but you can also add watchers to variables and put breakpoints on line numbers. Perhaps have a quick read through some gdb tutorials.
The program does not crash it just waits and waits... kwboot is basically a program which send data to a serial port.

This is what it looks like in practice.

The reason it doesn't work is probably due to the different ways FreeBSD and Linux access serial ports.

BTW how do you use gdb when the program is started with parameters?
 

Snurg

Aspiring Daemon

Thanks: 324
Messages: 795

#17
BTW how do you use gdb when the program is started with parameters?
at the end of the invoking command line --args <your program args>
You can use the -tui option, this makes gdb a bit easier to use with text ui.
An alternative would be to use a frontend. Personally I think I like kgdb. It uses the same F keys as MS CV. That makes it easy to use if you have experience with CV. There you have a menu item Arguments... Bad is that it has no text command interface, though. So you'll need gdb for more complex things.
 

kpedersen

Daemon

Thanks: 277
Messages: 1,086

#18
As Snurg said the --args parameter (or on the end of the 'r' gdb command such as 'r some/random/path'.

As for debugging programs that do not crash, you can use ctrl-c to interrupt the program where it looks to have frozen. From there you can see the stack trace with "where".

Your output would look something like this.

Code:
(gdb) r
Starting program: /home/kpedersen/Projects/sandbox/a.out
Hello World
^C
Program received signal SIGINT, Interrupt.
main () at src/main.cpp:12
12        while(true)
(gdb) where
#0  main () at src/main.cpp:12
 

balanga

Daemon

Thanks: 59
Messages: 1,961

#19
Code:
root@Test:~/Desktop # 
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'emacs' have been found in the repositories
root@Test:~/Desktop #
???????
pkg install emacs25!!!
 

jrm@

Daemon
Developer

Thanks: 450
Messages: 1,167

#20
Code:
root@Test:~/Desktop # pkg install emacs
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'emacs' have been found in the repositories
root@Test:~/Desktop #
???????
pkg install emacs25!!!
It is a coincidence that you ask this today. There was an overhaul of the Emacs infrastructure in the ports tree. There are now flavors and, relevlant to your question, the base package names no longer include the version. So, when the new packages roll out, it will be pkg install emacs (or alternatively one of: pkg install emacs-nox, pkg install emacs-canna, pkg install emacs-devel, pkg install emacs-devel_nox). See the commit log and the UPDATING entry for details.
 

jtotheh

New Member

Thanks: 1
Messages: 13

#23
Netbeans, though it is made for Java and built with Java, is actually an OK C/C++ IDE for FreeBSD. It's actually the best I've found. I haven't tried Eclipse for this though. QTCreator, though it is good on other OS's, doesn't work well for debugging on FreeBSD.
 

fnoyanisi

Active Member

Thanks: 97
Messages: 214

#24
come on, again the topic is bloated with lots of "you do not need a GUI for xxx" kind of answers (very common for answers to questions asking for text editors, IDEs etc.)...OP asks for an IDE, not a debugger CLI.

I am sorry guys, I have used gdb numerous times, but having a GUI (I am talking about an X-window desktop environment - xfce, kde, gnome, you name it- with windows etc, and I do not consider dozens of tiled terminals as a GUI) and being able to see locals, your watched variables, stack etc. makes life easier....
 

drhowarddrfine

Son of Beastie

Thanks: 724
Messages: 2,521

#25
fnoyanisi You are presuming one is not able to see those things without an IDE and that's not true. You also presume everyone else works like you do and, in our environment, that's definitely not true.
 
Top