I'm having trouble using lldb to debug on MacOsX with clang++. I'm using a makefile to compile a projet in C++, and I don't know if the debug option has to be enabled in the compilation command.
Here is an extract of my makefile
FLAGS =-g -Wall -O0
[...]
clang++ $(FLAGS) $^ -o $#
When I try running lldb with this configuration of my makefile, it return an error :
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
I suppose I have to enable the debug tools on my makefile, but I haven't found how to do this on internet. I tried with the -g and the -ggdb options, without success.
However, when I try to set a breakpoint differently, it works (but setting a breakpoint on a specific fonction doesn't interest me...) :
breakpoint set -n fonction
Breakpoint 1: [...]
I didn't manage to find answers on internet, so I would be interested in having some help ! Thank you !
It looks like somewhere along the way the debug information is getting lost. One possibility is that your CFLAGS are getting reset before you get to building the .o files you care about, so the .o files don't have debug info. One easy way to check that is run
$ otool -l my_file.o | grep debug_info
sectname __debug_info
If you don't see that "sectname" output, then your .o file has no debug information.
Run your makefile and look at the build line for my_file.c and make sure there really is a -g option being passed. -ggdb doesn't actually do anything special for clang so -g is all you need...
If the .o file has debug information, then it must be getting lost when you build the final binary.
Mac OS X is a little funny in how it handles debug information. It doesn't write the debug information into the final image, but rather writes a "debug-map" into the executable, and leaves the debug info in the .o file. That debug-map gets stripped when you strip a binary, so if you strip your executable that will remove the link to the debug information. And of course, if you delete the .o files after building, that will also remove the debug information.
I finally installed gdb, and I managed to debug normally. But after reading your post, you make me realize I have maybe delete the .o when compiling. I didn't thought about it, as lldb was able to set break point in some cases (at a specific fonction) but not in other cases (at a specific line).
As I am using a makefile, I forgot to delete the auto delete of all the .o after compiling, and I think that may cause the issue. Now, if I let the .o, that works perfectly. But this is surprising me a lot, as my makefile was the same as my colleague and he was able to debug with gdb without any kind of problem.
Thanks a lot for all your informations.
So, I am developing an OS and for now I've been only writing code in assembly. I wish to continue making it with C/C++.
The compiler/editor I use is FASM (for Windows). I've tried using MinGW with it, but it gives error when linking fasm's .o file.
How can I continue developing with both Assembly and C/C++?
Also, I've searched on the Internet a lot, but I didn't find a solution.
Edit:
this is the make batch file i'm using:
cls
echo off
fasm.exe los.asm losasm.o
pause
cls
"C:\MinGW\bin\gcc.exe" -nostdlib los.cpp -o loscpp.o
pause
cls
"C:\MinGW\bin\gcc.exe" -o "C:\Users\helder\Desktop\Lemperyum OperativeSystem I\los" -o -nostdlib losasm.o loscpp.o
pause
cls
pause
FASM is biased toward generating executable files directly as its output, the default being "flat binary output" (see manual). To create object files, you have to use one of the command line options
format COFF or
format ELF
Which you choose depends on the other tools. Offhand, I am not sure what type of file MinGW outputs.
I'm working on a toy bootloader/kernel written in assembly and run on the qemu emulator. I can run qemu with -s -S option and debug with gdb using remote target, but I don't have any debug symbols loaded with gdb. How can I generate a symbol file from my assembly?
I'm using nasm to generate a binary image for qemu to run from my assembly file, but I haven't found anyway to include debug information in the image itself (I'm not sure if that even makes sense). I also found that gdb allows you to load an separate symbol file for debugging, so now my issue is how to generate a symbol file from my assembly code.
I've seen suggestions to use objcopy, but I believe that only works on elf files, not binary. I've tried getting nasm to generate an elf, but it keeps barfing because of my (necessary) org directive in the assembly file.
It would say try it like this:
use "-f elf -F dwarf -g" switches when assembling. This should produce elf file that contains debug symbols (and code and everything else).
Use objcopy to generate binary file.
Load binary file to your system.
Attach debugger, then tell it to load symbols from your .elf file (symbol-file yourfile.elf)
You need to solve why nasm can't generate .elf file with .org you have in there. I have no idea. GNA as is fine with this.
$ nasm -g -f elf64 -l 2.lst 2.asm
$ gcc -m64 -o 2.exe 2.o
When I tried to debug an executable:
(gdb) break +1
No symbol table is loaded. Use the "file" command.
What does that mean exactly?
Is the symbol table appended to the executable?
There are two sets of symbols that gdb uses.
The -g set are debugging symbols, which make things a lot easier as they allow you to see your code and look at variables while debugging.
Another set of symbols is included by default when you compile. These are the linking symbols and live in the ELF (executable linkable format) symbol table. This contains a lot less info than the debug symbols, but contain the most important stuff, such as the addresses of the things in your executable (or library or object file). Without this information gdb won't even know where main is, so (gdb) break main would fail.
If you don't have the debugging symbols ( -g ) then you will still be able to (gdb) break main but you gdb will not have any concept of the lines of code in your source file. When you try to step through the code you will only advance 1 machine instruction at a time, rather than a line at a time.
The strip command is often used to strip off symbols from an executable (or other object file).
This is often used if you don't want someone to be able to see the symbols or if you want to save space in the file. Symbol tables can get big. Strip removes both the debug symbols and the linker symbols, but it has several command line switches which can limit what it removes.
If you run the file command on your program one of the things it will tell you is weather or not the executable is has been stripped.
$ gcc my_prog.c -o my_prog
$ file my_prog
my_prog: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
$ strip my_prog
my_prog: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
$
It's because you didn't compile with debugging turned on. Try gcc -g file.c
The symbol table contains debugging information that tells a debugger what memory locations correspond to which symbols (like function names and variable names) in the original source code file. The symbol table is usually stored inside the executable, yes.
gdb is telling you that it can't find that table. If you compiled with gcc, unless you used the -g flag, it will not include the symbol table in the file. The easiest method is probably to recompile your file with -g. gdb should then automatically find the symbol table information.
Either add the -g flag to the command line arguments of gcc or to the Makefile that you used to compile the program. (A lot of times, there will be a variable called CFLAGS or similar inside the Makefile).
If you are trying to debug an arbitrary third-party program, a lot of times the information will have been "stripped" out of it. This is done to make reverse engineering harder and to make the size of the executable file smaller. Unless you have access to the source code and can compile the program yourself, you will have a very hard time using gdb on it.
Find the entry point of the application.
objdump -f main
main: file format elf32-i386
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x08048054
Put a breakpoint there using the gnu debugger
gdb
exec-file main
break *0x8048054
set disassemble-next-line on
run
Then step through the code
gdb
stepi
Special Notes
If you are using the latest version of Ubuntu you would not be affected by this, but you may run into this bug if you are running Ubuntu 10.04 or older.
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/151518G
The solution would be to start debugging at the entry point address plus one.
How can I compile/run C or C++ code in a Unix console or a Mac terminal?
If it is a simple single-source program,
make foo
where the source file is foo.c, foo.cpp, etc., you don’t even need a makefile. Make has enough built-in rules to build your source file into an executable of the same name, minus the extension.
Running the executable just built is the same as running any program - but you will most often need to specify the path to the executable as the shell will only search what is in $PATH to find executables, and most often that does not include the current directory (.).
So to run the built executable foo:
./foo
gcc main.cpp -o main.out
./main.out
This is the command that works on all Unix machines... I use it on Linux/Ubuntu, but it works in OS X as well. Type the following command in Terminal.app.
g++ -o lab21 iterative.cpp
-o is the letter O, not zero
lab21 will be your executable file
iterative.cpp is your C++ file
After you run that command, type the following in the terminal to run your program:
./lab21
Two steps for me:
First:
make foo
Then:
./foo
All application execution in a Unix (Linux, Mac OS X, AIX, etc.) environment depends on the executable search path.
You can display this path in the terminal with this command:
echo $PATH
On Mac OS X (by default) this will display the following colon separated search path:
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
So any executable in the listed directories can by run just by typing in their name. For example:
cat mytextfile.txt
This runs /bin/cat and displays mytextfile.txt to the terminal.
To run any other command that is not in the executable search path requires that you qualify the path to the executable. So say I had an executable called MyProgram in my home directory on Mac OS X I can fully qualify it like so:
/Users/oliver/MyProgram
If you are in a location that is near the program you wished to execute you can qualify the name with a partial path. For example, if MyProgram was in the directory /Users/oliver/MyProject I and I was in my home directory I can qualify the executable name like this, and have it execute:
MyProject/MyProgram
Or say I was in the directory /Users/oliver/MyProject2 and I wanted to execute /Users/oliver/MyProject/MyProgram I can use a relative path like this, to execute it:
../MyProject/MyProgram
Similarly if I am in the same directory as MyProgram I need to use a "current directory" relative path. The current directory you are in is the period character followed by a slash. For example:
./MyProgram
To determine which directory you are currently in use the pwd command.
If you are commonly putting programs in a place on your hard disk that you wish to run without having to qualify their names. For example, if you have a "bin" directory in your home directory for regularly used shell scripts of other programs it may be wise to alter your executable search path.
This can be does easily by either creating or editing the existing .bash_profile file in your home directory and adding the lines:
#!/bin/sh
export PATH=$PATH:~/bin
Here the tilde (~) character is being used as a shortcut for /Users/oliver. Also note that the hash bang (#!) line needs to be the first line of the file (if it doesn't already exist). Note also that this technique requires that your login shell be bash (the default on Mac OS X and most Linux distributions). Also note that if you want your programs installed in ~/bin to be used in preference to system executables your should reorder the export statement as follows:
export PATH=~/bin:$PATH
Do all of this in "Terminal".
To use the G++ compiler, you need to do this:
Navigate to the directory in which you stored the *.cpp file.
cd ~/programs/myprograms/
(the ~ is a shortcut for your home, i.e. /Users/Ryan/programs/myprograms/, replace with the location you actually used.)
Compile it
g++ input.cpp -o output.bin (output.bin can be anything with any extension, really. Extension .bin is just common on Unix.)
There should be nothing returned if it was successful, and that is okay. Generally you get returns on failures.
However, if you type ls, you will see the list of files in the same directory. For example, you would see the other folders, input.cpp and output.bin
From inside the directory, now execute it with ./outbut.bin
A compact way to go about doing that could be:
make foo && ./$_
It is nice to have a one-liner so you can just rerun your executable again easily.
Assuming the current directory is not in the path, the syntax is ./[name of the program].
For example ./a.out
To compile C or C++ programs, there is a common command:
make filename
./filename
make will build your source file into an executable file with the same name. But if you want to use the standard way, You could use the gcc compiler to build C programs and g++ for C++.
For C:
gcc filename.c
./a.out
For C++:
g++ filename.cpp
./a.out
Add the following to get the best warnings, and you will not regret it. If you can, compile using WISE (warning is error).
- Wall -pedantic -Weffc++ -Werror
Step 1 - create a cpp file using the command
touch test.cpp
Step 2 - Run this command
g++ test.cpp
Step 3 - Run your cpp file
./a.out
I am on a new MacBook Pro with the Apple M1 Pro chip. I have my Xcode installed - both IDE and command line tools. This is how it worked for me:
g++ one.cpp -o one
./one
Use a makefile. Even for very small (= one-file) projects, the effort is probably worth it because you can have several sets of compiler settings to test things. Debugging and deployment works much easier this way.
Read the make manual. It seems quite long at first glance, but most sections you can just skim over. All in all, it took me a few hours and made me much more productive.
I found this link with directions:
http://www.wesg.ca/2007/11/how-to-write-and-compile-c-programs-on-mac-os-x/
Basically you do:
gcc hello.c
./a.out (or with the output file of the first command)
In order to compile and run C++ source code from a Mac terminal, one needs to do the following:
If the path of .cpp file is somePath/fileName.cpp, first go the directory with path somePath
To compile fileName.cpp, type c++ fileName.cpp -o fileName
To run the program, type ./fileName
Just enter in the directory in which your .c/.cpp file is.
For compiling and running C code.
gcc filename.c
./a.out filename.c
For compiling and running C++ code.
g++ filename.cpp
./a.out filename.cpp
You need to go into the folder where you have saved your file.
To compile the code: gcc fileName
You can also use the g++ fileName
This will compile your code and create a binary.
Now look for the binary in the same folder and run it.
For running C++ files, run the below command, assuming the file name is "main.cpp".
Compile to make an object file from C++ file.
g++ -c main.cpp -o main.o
Since #include <conio.h> is not supported on macOS, we should use its alternative which is supported on Mac. That is #include <curses.h>. Now the object file needs to be converted to an executable file. To use file curses.h, we have to use library -lcurses.
g++ -o main main.o -lcurses
Now run the executable.
./main
Running a .C file using the terminal is a two-step process.
The first step is to type gcc in the terminal and drop the .C file to the terminal, and then press Enter:
gcc /Desktop/test.c
In the second step, run the following command:
~/a.out