preprocessed object files

This document describes observations related to object files created when adding a preprocessing step to the compile process.  These objects files were created to help discover why using ccache and/o preprocessing source files causes lldb to be unable to set breakpoints.

This is also a continuation of the items discussed in document “lldb and ccache” and “lldb and ccache, part 2”.

On the mac, “gobjdump -t” was used to inspect symbols in object files 

Step 1
main1.cpp contains
int main(int argc, char const *argv[])
{
	return 0;
}

when compiled with
	clang -g -m64 -O0 -o main1.out main1.cpp

main1.out has the following symbols
SYMBOL TABLE:
0000000000000000      d  64 SO     00 0000 /Users/bsi/google/lldb/git/lldb/test/functionalities/preprocessor/
0000000000000000      d  64 SO     00 0000 main1.cpp
0000000053fbb472      d  66 OSO    03 0001 /var/folders/nk/p_jvjzrj0kg487v_340hwxn40000gn/T/main1-7b545d.o
0000000100000f80      d  2e BNSYM  01 0000 
0000000100000f80      d  24 FUN    01 0000 _main
0000000000000019      d  24 FUN    00 0000 
0000000000000019      d  4e ENSYM  01 0000 
0000000000000000      d  64 SO     01 0000 
0000000100000000 g       0f SECT   01 0010 [.text] __mh_execute_header
0000000100000f80 g       0f SECT   01 0000 [.text] _main
0000000000000000 g       01 UND    00 0100 dyld_stub_binder

Step 2
when compiled with
	clang -E -g -m64 -O0 -o main2.cpp main1.cpp
	clang -g -m64 -O0 -o main2.out main2.cpp

main2.cpp contains:
# 1 "main1.cpp"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 175 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "main1.cpp" 2
int main(int argc, char const *argv[])
{
 return 0;
}

and main2.out contains the following symbols:
SYMBOL TABLE:
0000000000000000      d  64 SO     00 0000 /Users/bsi/google/lldb/git/lldb/test/functionalities/preprocessor/
0000000000000000      d  64 SO     00 0000 main2.cpp
0000000053fbafd4      d  66 OSO    03 0001 /var/folders/nk/p_jvjzrj0kg487v_340hwxn40000gn/T/main2-264e85.o
0000000100000f80      d  2e BNSYM  01 0000 
0000000100000f80      d  24 FUN    01 0000 _main
0000000000000000      d  84 SOL    00 0000 main1.cpp
0000000000000019      d  24 FUN    00 0000 
0000000000000019      d  4e ENSYM  01 0000 
0000000000000000      d  64 SO     01 0000 
0000000100000000 g       0f SECT   01 0010 [.text] __mh_execute_header
0000000100000f80 g       0f SECT   01 0000 [.text] _main
0000000000000000 g       01 UND    00 0100 dyld_stub_binder

Step 3
when main1.cpp is copied to main3.cpp and compiled with
	clang -E -g -m64 -O0 -o main3.cpp main3.cpp
	clang -g -m64 -O0 -o main3.out main3.cpp

main3.cpp contains:
# 1 "main3.cpp"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 175 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "main3.cpp" 2
int main(int argc, char const *argv[])
{
 return 0;
}

and main3.out contains the following symbols:
SYMBOL TABLE:
0000000000000000      d  64 SO     00 0000 /Users/bsi/google/lldb/git/lldb/test/functionalities/preprocessor/
0000000000000000      d  64 SO     00 0000 main3.cpp
0000000053fbafde      d  66 OSO    03 0001 /var/folders/nk/p_jvjzrj0kg487v_340hwxn40000gn/T/main3-ec7559.o
0000000100000f80      d  2e BNSYM  01 0000 
0000000100000f80      d  24 FUN    01 0000 _main
0000000000000019      d  24 FUN    00 0000 
0000000000000019      d  4e ENSYM  01 0000 
0000000000000000      d  64 SO     01 0000 
0000000100000000 g       0f SECT   01 0010 [.text] __mh_execute_header
0000000100000f80 g       0f SECT   01 0000 [.text] _main
0000000000000000 g       01 UND    00 0100 dyld_stub_binder

Observations
lldb is able to set breakpoints in main1.out and main3.out, but not in main2.out.  This seems to be related to the sixth symbol in the main2.out labelled “main1.cpp” of type “SOL”.  “main1.cpp” is the name of the original source file and is different from the name of the preprocessed file.  It is also the the only symbol with type “SOL” in any of the three object files.  It seems similar to the symbols of type “SO”.

According to the following lines from mach-o/stab.h, “SOL” seems to be a #included file name.  This symbol type does not seem to be handled well by lldb.
#define	N_SO		0x64	/* source file name: name,,n_sect,0,address */
#define	N_OSO	0x66	/* object file name: name,,0,0,st_mtime */ #define	N_SOL	0x84	/* #included file name: name,,n_sect,0,address */

In lldb, ObjectFileMachO.cpp has many references to N_SO and N_SOL.