__BASE_FILE__ does not mean "the basename of the current file"; it means what Clang calls "the main source file", i.e. your .c file, even when written in a .h file. So really it's back to optimization.
Jordan > On Sep 18, 2014, at 10:40, Iritscen <irits...@yahoo.com> wrote: > > Hello all. My question starts off touching on llvm, but then comes back to > clang, so please let me know if any of this belongs on an llvm mailing list. > > I am striving to avoid any paths from my hard drive ending up in the binary I > am producing, and the code I am building uses __FILE__ for logging. When I > researched solutions for avoiding the full paths from expansions of __FILE__, > they all seemed to be performed at run-time even when the intent seems to > have been for them to work at compile-time. This does not help, as my goal > is to avoid any paths (above the project folder, at least) from being found > in the binary on disk. > > For instance, the suggestion to make a define like: > > #define __FILE_NAME__ (strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : > __FILE__) > > does not avoid full paths being stored in the binary because it does not > optimize down to only the file name at compile-time, no matter how high I > turn up the optimization. Nor does this simpler example optimize at > compile-time: > > const char* const THIS_FILE_NAME = strrchr(__FILE__, '/') + 1; > > I can see that there are optimizations for string functions in llvm's > SimplifyLibCalls.cpp, but they don’t seem to be used when I build at any -O > level. If I’m not mistaken, the comment above > InstCombiner::tryOptimizeCall() in InstCombineCalls.cpp explains why: > > "// Try to fold some different type of calls here. > // Currently we're only working with the checking functions, memcpy_chk, > // mempcpy_chk, memmove_chk, memset_chk, strcpy_chk, stpcpy_chk, strncpy_chk, > // strcat_chk and strncat_chk.” > > It seems that the optimization functions for strchr(), strcat(), etc. are > simply never called by llvm, but I could be wrong. > > That’s why I was excited to read about __BASE_FILE__... until I saw that it > simply produces the same output as __FILE__. According to various Internet > searches, __BASE_FILE__ simply uses the path passed in to clang, just like > __FILE__ does. This is a problem, because according to what I’ve read, it > doesn’t seem to be possible to get my IDE, Xcode, to pass relative paths to > clang. There are various “relative path” settings that Xcode offers for > storing file references in the project, but these always seem to be resolved > to full paths when invoking clang. > > However, clang’s PPMacroExpansion.cpp has this puzzling comment: "// > __BASE_FILE__ is a GNU extension that returns the top of the presumed > #include stack instead of the current file.” I’m not sure what that means; > is it returning the file path relative to the highest common directory in the > #include file tree? Why would it do that? > > The documentation for GCC’s original __BASE_FILE__ is, in its entirety: "This > macro expands to the name of the main input file, in the form of a C string > constant. This is the source file that was specified on the command line of > the preprocessor or C compiler.” That seems to be saying that the file name > will be picked out from whatever path, relative or absolute, is used to pass > the file to the compiler. > > Shouldn’t clang follow this guideline? And if not, why isn’t there any macro > for just getting a source file's name? Thanks in advance for any answers > that you guys have for me. > _______________________________________________ > cfe-users mailing list > cfe-users@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users _______________________________________________ cfe-users mailing list cfe-users@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users
