Learn C programming fundamentals like data types, control flow, functions, pointers, and memory allocation while exploring debugging, profiling, and optimization tools like GDB and gcc.

clang.tar.gz

RunC

RunCwithGNUflags

RunCwithlmflag

Run_go_file 

RunC-without_warning_flag

Compile-only

doNothing

Posix

RunCFileGo

Compile-go-file

Compile-go-debugging-file

OpenMP

Make

MPI4Threads

MPI8Threads

Octave

RunC-without_warning_flag-KS

This comprehensive course covers the fundamentals and advanced concepts of C programming to build a solid foundation for your programming journey. You’ll learn about essential topics like data types, variables, constants, and C statements, along with deeper explorations of control flow in C, including for loops and conditional statements in C. You’ll also learn about C functions, scope of variables, function arguments, and work with arrays, strings, and pointers in C.

You’ll gain hands-on experience with dynamic memory allocation, stack vs. heap, C standard library, and advanced topics such as binary files, input and output streams, and header files. The course also teaches compiling in C, linking in C, and debugging with tools like GNU debugger (GDB) and gprof for code profiling. By mastering these concepts, you’ll confidently program in C and optimize your code using gcc optimization flags.

Learn C

**Debugging** is the process of identifying the source of errors or bugs in our code, and analyzing the reasons for it. It can help with fixing code crashes, removing logical mistakes, and making our program more efficient. 

# What is a symbolic debugger?

A **debugger** is a program that runs other programs, and provides the ability to control the execution of that program, for example, by stepping through one line at a time, and inspecting variables as our program runs. When our program crashes, and UNIX gives us a vague error message, a debugger helps us figure out where it's crashing, and (with the assistance of our brain) why it's crashing.

## Why not use `printf`?

A quick and easy method of debugging that doesn’t require a separate debugger program, is to sprinkle your code with `printf` statements that write to the screen, the values of various variables that you think are relevant and related to a crash (or other error). Some people call this adding “trace code” to your program.

The disadvantages of debugging using trace code are that we may need many `printf` statements all over the program, and it becomes a nuisance to put them in, take them out, etc. Moreover, a symbolic debugger can do a lot more stuff than simple trace code. It can:
 - halt a program
 - allow us to inspect variable values 
 - jump to an arbitrary line of code 
 - evaluate expressions 
 - restart from where we left off

We just get more fine-grained control by using a debugger. Finally, we can use the gdb debugger on a program that has already crashed, without having to restart the program. With that we'll see the state of the program and its variables, at the time of the crash, allowing us to inspect the values of the variables, the location in the program of the crash, etc.

# Compiling a program for GDB

GNU Debugger (GDB) is a debugger that's widely used by C developers.
To allow GDB to run our program, we must compile our program with a special compiler flag, `-g`. Here's a simple example of a program `go.c` that we'll use to illustrate how GDB is used:



Learn about the GNU Debugger (GDB), which is a powerful debugging tool for C, and learn how to run it and view a stack trace with it.

The GNU Project Debugger (GDB)

Introduction to C Programming

Data Types in C

C Operators and C Expressions

Control Flow in C

Functions in C

Complex Data Types

Stack vs. Heap

Pointers in C

C string

Input and Output Stream

Macros and the C Preprocessor

Header Files, Compiling and Linking

C Debugger

Code Profiling

Parallel Programming in C

Project: Using a Bootstrapped t-test

Conclusion

Miscellaneous

Appendix: Setting Up the Environment

The GNU Project Debugger (GDB)

What is a symbolic debugger?

Why not use `printf`?

Project: Using a Bootstrapped t-test

The GNU Project Debugger (GDB)

What is a symbolic debugger?

Why not use printf?

Why not use `printf`?