lldb and preprocessed files

This is a continuation of findings related to lldb and ccache interactions that are described in the document “lldb and ccache”.

One of the main things that ccache does is to preprocess the source file.  To see how this affects lldb, i tried doing a preprocess step without using ccache.  

In order to debug lldb in xcode, i moved my tests from ubuntu to the mac.  This migration does not seem to change the interaction between ccache and lldb.

Step 1
Create an even simpler source file, “main1.cpp”:
int main(int argc, char const *argv[])
{
	return 0;
}

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

lldb has no problem loading main1.out and setting a breakpoint on line 3 (“return 0;”).

Step 2
When i introduce a preprocess step with
	clang -E -g -m64 -O0 -o main2.cpp main1.cpp
	clang -g -m64 -O0 -main2.out main2.cpp

this creates the following source file, "main2.cpp":
# 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;
}
when main2.out is loaded into lldb, lldb is not able to set a breakpoint at line 3 or line 9 (“return 0;” is line 3 in main1.cpp and line 9 in main2.cpp)

Step 3
Copy main1.cpp to main3.cpp.  Preprocess the source file without using a secondary, intermediate file name with:
	clang -E -g -m64 -O0 -o main3.cpp main3.cpp
	clang -g -m64 -O0 -main3.out main3.cpp

this creates the following source file, “main3.cpp”:
# 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;
}

lldb is able to load main3.out and set a breakpoint at line 3.

The source files used in steps 2 and 3 are the same other than the source file referenced on lines 1 and 7 are for the original file in step 2 and the original and preprocessed file in step 3.

Observation(s)
The inability to set a breakpoint on line 3 of the preprocessed file seems to be related to using a different secondary name for the preprocess step.

gdb is able to set a breakpoint on line 3 for all of the different executables created in steps 1 thru 3