I'm writing a small C library for some basic polygon operations and I'm trying to use LLDB from the command line for debugging. I am able to run LLDB with my compiled test runner, but I can only see assembly instructions and not C code as I step through.
I've compiled my library and test runner with the -g flag as shown here in this Makefile:
#Define compiler flags
CFLAGS = -g -Wall -Werror
#Define objects
OBJECTS = MASClip.o MASGraph.o MASClipTest.o
tests : $(OBJECTS)
cc $(CFLAGS) $(OBJECTS) -o tests
MASClip.o : MASClip.h MASClip.c
cc $(CFLAGS) -c MASClip.c
MASGraph.o : MASGraph.h MASGraph.c
cc $(CFLAGS) -c MASGraph.c
MASClipTest.o : MASClipTest.c
cc $(CFLAGS) -c MASClipTest.c
test :
make
make clean
./tests
.PHONY : clean
clean :
rm *.o
I can set breakpoints by function name so I don't understand why the code is not displayed.
I've searched around, but I don't see that I'm doing anything different from what the tutorials and other questions say. I must be missing something obvious.
Also, I realise I could just do this in Xcode, but when I write straight C I like to use VIM and it would be nice to be able to use LLDB from the command line.
How do I get LLDB to display the actual C code when debugging?
On OS X debug info is stored in .o files. The debugger refers back to the .o files using a "debug map" in the executable. Looks like you are deleting the .o files before you try to debug, so there's no debug information for the debugger.
Either leave the .o files in place when you debug, or run the dsymutil tool on the executable to produce a linked debug output file (.dSYM.) If you put the dSYM next to the executable (or anywhere that Spotlight searches) then lldb will find it automatically.
Note that if you just give the compiler a list of .c files, it will make a dSYM for you automatically - since it will delete the .o files when it is done - so that debugging is still possible.
Related
I am currently learning C with the book "Learn C The Hard Way" and looked into reverse engineering as well. What I want to do is read through the compiler generated assembly for the C programs I have written. I know the option for gcc here is gcc -S -masm=intel file.c.
My question now is: can I automatically have gcc create the .s file and the .out file using the Makefile?
My previous Makefiles always looked like this:
CC=gcc
CLFAGS=-Wall -g
all: file
clean:
rm -f file
How can I extend my Makefile to make it work?
You could do something like the following:
CC=gcc
CFLAGS=-Wall -Werror -Wextra -O2 -g
SOURCE=file.c
all: binary assembly
binary: $(SOURCE)
$(CC) $(CFLAGS) $(SOURCE)
assembly: $(SOURCE)
$(CC) $(CFLAGS) -fverbose-asm -S -masm=intel $(SOURCE)
clean:
rm -f file.s a.out
And use it like this:
$ make # same as `make all`
$ make all # makes both executable (binary) and assembly
$ make binary # makes binary file only
$ make assembly # makes assembly only
It seems that you can execute other labels from other labels. However
how do they differ from just writing the desired filename like I did?
Remember that Makefiles consist of "rules" with the format:
target: dependencies
system command(s)
See more here.
The make program decides on what should be done based on how you invoke it and how you define your rules. For example, the first rule with target all depends on binary and assembly, so make checks those rules, and carries out the relevant steps (in this case executing gcc).
How does gcc differentiate between them?
The gcc program is a compiler, which is a completely separate program. It is merely invoked by make, just like rm is for the clean rule. It has no involvement in processing the Makefile itself, so it doesn't need to "differentiate" anything -- make does all the processing of the Makefile.
Also, the $() variables you use, do they only exist for gcc or could
you also define them globally in your operating system?
The variables have nothing to do with gcc. The make program parses the Makefile and performs the necessary substitutions before invoking the commands (e.g. gcc).
The variables could be used elsewhere in the Makefile too, for example with the rm command. They are not specific to any command in particular.
You can also make use of environment variables in a Makefile, as explained in this post.
This is my absolute first time ever making a makefile, and I'm really trying to understand the process.
I'm trying to create a very simple makefile for a C++ project whose structure is as follows:
root folder
makefile
readme
src folder
...source files all here...
include folder
...header files for external libraries here...
lib folder
...external lib files all here...
bin folder
...output directory for built executable...
obj folder
...object files all here...
I followed the tutorial here.
Here's my makefile:
IDIR=include .
CC=g++
CFLAGS=-I$(IDIR)
ODIR=bin/obj
LDIR=lib
LIBS=none
SRC=src
_DEPS=hello.h
DEPS=$(patsubst %,$(IDIR)/,%(_DEPS))
_OBJ=file1.o file2.o
OBJ=$(patsubst %,$(ODIR)/%,$(_OBJ))
$(ODIR)/%.o: $(SRC)/%.cpp $(DEPS)
$(CC) -c -o $# $< $(CFLAGS) # $(LIBS)
test_proj: $(OBJ)
$(CC) -o $# $^ $(CFLAGS)
.PHONY: clean
clean:
rm -f $(ODIR)/*.o *~ core $(INCDIR)/*~
When I run make on this, I get the following error:
g++ -o .o
g++: fatal error: no input files
compilation terminated.
<builtin>: recipe for target '.o' failed
mingw32-make.exe: *** [.o] Error 1
I'm using GNU Make 3.82.90 built for i686-pc-mingw32, if that matters at all.
Can anyone point out whatever ridiculous error I'm making?
IDIR=include .
is the first problem. Replace it by:
IDIR=include
With your code CFLAGS is expanded as:
-Iinclude .
It does not make sense, I'm afraid. The second problem is:
DEPS=$(patsubst %,$(IDIR)/,%(_DEPS))
which should probably be:
DEPS=$(patsubst %,$(IDIR)/%,$(_DEPS))
and would expand as:
DEPS=include/hello.h
if you fix the first problem, else as:
DEPS=include ./hello.h
which does not make sense neither. The cumulated effect of these two errors are strange recipes (I didn't try to expand them by hand) that probably trigger a make implicit rule with wrong parameters.
IDIR=include .
CC=g++
CFLAGS=-I$(IDIR)
This is wrong. First, for C++ code, use CXX not CC and CXXFLAGS not CFLAGS. Run make -p to understand the builtin rules of your make.
Then -I$(IDIR) does not "distribute" the -I, and IDIR is never used elsewhere. So I suggest to start your Makefile with:
CXX=g++
MY_CXX_LANG_FLAGS= -std=c++11
MY_CXX_WARN_FLAGS= -Wall -Wextra
MY_CXX_INCL_FLAGS= -I. -Iinclude
MY_CXX_MACRO_FLAGS= -DMYFOO=32
### replace with -O2 for a release build below
MY_CXX_OPTIM_FLAGS= -g
CXXFLAGS= $(MY_CXX_LANG_FLAGS) $(MY_CXX_WARN_FLAGS) \
$(MY_CXX_INCL_FLAGS) $(MY_CXX_MACRO_FLAGS)
I won't improve your Makefile, but I do suggest to upgrade to GNU make version 4 if possible (and compiling make 4.1 from its source code is worthwhile in 2015) for that purpose. If possible enable GUILE scripting in it.
If you are forced to use make 3.82 debug your Makefile using remake (with -x); if you can afford a make version 4 use its --trace option
BTW, you might consider using automatic dependencies, that is generating dependencies by passing -M or -MG (etc) flags of g++, see that.
At last, a simple project for a small program (less than a hundred thousands of source lines) might just put all (a few dozens of) its files in the current directory (then the Makefile could be simpler); your proposed directory structure might be arcane for a simple project (but could worth the pain if you have millions of C++ source lines of code). I've given several simple examples of Makefile, e.g. this & that. And GNU make source code itself has a less complex file tree that what you want.
BTW, I strongly disagree with the opinions of that answer (which I did upvote, since it is helpful). I don't feel that GNU make is senile, but I regret that, instead of using recent features available on recent versions (4.x) of make, many people prefer to use complex and arcane Makefile generators (like cmake) instead of coding a clever Makefile (for make version 4 specifically).
At last, you could use other builders, e.g. omake, icmake, ....
I created a simple makefile to understand the basic idea behind how they work and it's not performing the way I expected. Please see the following:
test: test.c
gcc -o test test.c
My understanding is this should only run when there have been changes to the test.c file. The problem is it runs every time regardless of whether or not there were changes.
I've noticed that this occurs when I use arbitrary target names. If I make the target name an actual file name such as "test.exe", it works correctly, but all the tutorials I've seen show dependencies working with arbitrary target names. Any idea as to why this is occurring?
Under Windows, Make automatically adds the suffix .exe to the generated program.
Since the name of the target is different from the result of the rule, Make tries to generate it again.
You should write your makefile like this:
EXE := test.exe
$(EXE): test.c
gcc -o $# $^
If you need portability and don't want to rewrite the rule, use this:
EXE := test
if ($(OS),Windows_NT)
EXE := $(EXE).exe
endif
$(EXE): test.c
gcc -o $# $^
See, the problem is that I'm supposed to use an executable driver program (vdriver) to test the C source file I wrote (myfile.c) containing a collection of methods the driver program will use. I used gcc to compile them together (and also any files they depend on) and then ran "gdb vdriver"
Apparently, I am getting a segfault somewhere in myfile.c. The "dissasemble"-produced assembly code can even display the whole method in assembly and point to which instruction just segfaulted.
However, due to the complexity (and length) of the assembly code, I think it would be much more effective to view this line where the segfault occurred in C.
However, running the command "list *$eip" results in:
No source file for address 0x804a3d3
Does anyone know how to make this work?
Compile with debugging info.
gcc -ggdb -c source.c -o source.o ...
Update: It looks like you're having trouble invoking GCC as well. I suggest writing a Makefile, and taking a quick look through the GCC manual for what -c and -o mean.
CC = gcc
CFLAGS = -ggdb -Wall # or whatever flags you want, read the manual
# List all files, with *.c changed to *.o (Make will figure the rest out)
my_app : file1.o file2.o file3.o file4.o
$(CC) -o my_app $^
# The above line should start with a tab, not spaces
clean :
rm -f my_app *.o
# List dependencies like this (technically optional)
# But if you don't do it, "make" might not re-make things that need it
file1.o : file1.c header.h header2.h
file2.o : file2.c header.h
(I am running Linux Ubuntu 9.10, so the extension for an executable is executablefile.out) I am just getting into modular programming (programming with multiple files) in C and I want to know how to compile multiple files in a single makefile. For example, what would be the makefile to compile these files: main.c, dbAdapter.c, dbAdapter.h? (By the way, If you haven't figured it out yet, the main function is in main.c) Also could someone post a link to the documentation of a makefile?
The links posted are all good. For you particular case you can try this. Essentially all Makefiles follow this pattern. Everything else is shortcuts and macros.
program: main.o dbAdapter.o
gcc -o program main.o dbAdapter.o
main.o: main.c dbAdapter.h
gcc -c main.c
dbAdapter.o dbAdapter.c dbAdapter.h
gcc -c dbAdapter.c
The key thing here is that the Makefile looks at rules sequentially and builds as certain items are needed.
It will first look at program and see that to build program, it needs something called main.o and dbAdapter.o.
It will then find main.o. However, to build main.o, it will need main.c and dbAdapter.h (I assume dbAdapter.h is included in main.c).
It will use those sources to build main.o by compiling it using gcc. The -c indicates the we only want to compile.
It does the same thing with dbAdapter.o. When it has those two object files, it is ready to link them. It uses the gcc compiler for this step as well. The -o indicates that we are creating a file called program.
GNU make should be what you're looking for.