3

This may be compiler specific, in which case I am using the IAR EWARM 5.50 compiler (firmware development for the STM32 chip).

Our project consists of a bunch of C-code libraries that we compile first, and then the main application which compiles its C-code and then links in those libraries (pretty standard stuff).

However, if I use a hex editor and open up any of the library object files produced or the final application binary, I find a whole bunch of plain text references inside the output binary to the file paths of the C files that were compiled. (eg. I see "C:\Development\trunk\Common\Encryption\SHA_1.c")

Two issues with this:

  • we don't really want the file paths being easily readable as that indicates our design some what
  • the size of the binary grows if you have your C-files located in a long subdirectory (the binary contains the full path, not just the name)...this is especially important when we're dealing with firmware that has a limited amount of code space (256KB).

Any thoughts on this? I've tried all the switches in the compiler I can think of to "remove debug information", etc., but those paths are still in there.

Matt
  • 33
  • 3
  • That's debug info. Strip debug and the stuff should go away. – Hot Licks Aug 01 '13 at 15:35
  • Its not debug information if its a const string, since it will be in the data section – KrisSodroski Aug 01 '13 at 15:36
  • This seems like a good question to ask your toolchain vendor. – Casey Aug 01 '13 at 16:32
  • @Magn3s1um - If it's a const string that implies it's coded into the app, and the obvious solution is to change the code. But it sure sounds like debug info. – Hot Licks Aug 01 '13 at 17:22
  • (You might check for any debug macros being used, such as `__FILE__`.) – Hot Licks Aug 01 '13 at 17:25
  • @HotLicks : It is definitely not hardcoded literals in the source, as it changes for each of our team members (since they have the source located in the different places). But you're right, it may be the __FILE__ macro, I'll look into that. – Matt Aug 01 '13 at 17:36
  • @Casey : I have asked the toolchain vendor (IAR Systems), but they are not very helpful unless you have a support contract, which is very expensive. I really wish we would have chosen a toolsuite that was based on GCC, but that bridge was crossed a long time ago. – Matt Aug 01 '13 at 17:39
  • Be sure to look EVERYWHERE for the `__FILE__` macro -- some of the include files used by debug code may be in an oddball include path and could be missed on a cursory scan. – Hot Licks Aug 01 '13 at 18:49

1 Answers1

5

"The command-line option --no_path_in_file_macros has been added. It removes the path leaving only the filename for the symbols FILE and BASE_FILE." It is defined in the release notes if IAR.

http://supp.iar.com/FilesPublic/UPDINFO/005832/arm/doc/infocenter/iccarm_history.ENU.html

Or you can look for FILE and BASE_FILE macros and remove it you do not want to use the flag.

roohul
  • 66
  • 1
  • Yup, this solved the problem..thanks! It was the __FILE__ macro somewhere, but instead of hunting it down, using this option in the compiler addressed my concerns. And a shout out to @HotLicks for original thought on that macro! – Matt Aug 02 '13 at 15:36
  • I had a similar issue where the converted HEX files were different, depending on where the sources were checked out. The answer to this question has helped me greatly! It turns out that the `__FILE__` macro was used implicitly in two files, by using `assert()`. – Ruud Althuizen Sep 01 '14 at 13:58