This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/LAUNCHXL-F28377S: Why is _printfi.obj being linked from rts2800_fpu32.lib?

Part Number: LAUNCHXL-F28377S

Tool/software: TI C/C++ Compiler

I specifically am not using the stdout printf function. (in fact stdout is not included at all). Yet, I noticed in the map file that _printfi.obj shows up under /ccsv7/tools/compiler/ti-cgt-c2000_16.9.1.LTS/lib/rts2800_fpu32.lib. It's taking up 3094 bytes, which isn't a small fraction of the total used.

I'm not sure, however, how to track down what could be causing this.

  • Moving this thread to the TI C/C++ Compiler forum

    Sean
  • Thanks!  Although the compiler flag never shows up, the Language Options in CCS (under C2000 Compiler) does have the "level of printf support". Sadly there is no way to select the blank option. The minimal option does decrease the wasted space dramatically. However, I'm curious why the rts library is automatically including so much, when I'm not calling any of the functions.

  • Adam Jones said:
    I'm not sure, however, how to track down what could be causing this.

    The functions in _printfi.obj are used by all the members of the printf family.  I recommend you search the linker map file to see which one it is.  In a CCS project, the map file is located in a folder named Debug or Release (or whatever the current build configuration is), and called name of project.map.  Once you know the name of the function, then search all of your source code for it. Header files too.

    While I'm pretty sure this suggestion will work, there is no guarantee.  If it doesn't work out, let us know what you did find.  I'm sure we will track it down.

    Thanks and regards,

    -George

  • Thank you, George, for getting back with me.

    I've done a full text search with all of the headers that I include (or even had associated, in the same folders). And there were two IQmath headers that had references to printf - which I've now just deleted. Now, there are tons of references to printf in ccsv7/tools/compiler/ti-cgt-c2000_16.9.1.LTS/include. However, I'm not including any of those headers in my own code. Nor am I calling printf, or any of it's associated functions.

    I should add that I am using a printf-like implementation that I got from GitHub (xformatc, for those who are interested) which I then wrapped inside a function called printf (just for familiarity). However, I don't call stdio anywhere.

    I've been using the map file for lots of things, so I know how to navigate it (and I wish I would've thought of it earlier this week when I was tracking down a bug were the CLA couldn't read from a variable that I had mistyped in the pragma data_section). Anyways. There are 52 obj being compiled from rts2800_fpu.lib (using 6k), but I see no way to tell why they were chosen. I just have them referenced like this:

                      00014e38    00000014     rts2800_fpu32.lib : _printfi_min.obj (.econst:.string)

                      00014e4c    00000014                       : strtod.obj (.econst:_digits)

    At this point, maybe because it's only using up 6k, I should just leave it be. I'm just really curious why all of this code is being included, that I'm not calling directly

  • Here is another way to see what calls the functions in _printfi*.obj.  This command is run from the Windows command line.  It is applied to the final linked .out file created by your project.

    C:\path\to\project>nm2000 file.out | find "print"

    The command nm2000 dumps out all of the symbols in the executable file.  The Windows command "find" filters through all those symbols that include the text "print".  This will show you which variant of printf is using the _printfi functions.

    More background on nm2000 ... This is the names utility.  It is yet another executable supplied with the compiler tools.  Please read more about it in the C2000 assembly tools manual.

    I'm sorry I didn't think of this idea sooner.

    Thanks and regards,

    -George

  • George,

    Thank you. The out file is showing the same results as the map file, that both ___TI_printfi_minimal and _fprintf are inside the compiled file (along with _fputc, _fputs and dozens of other functions that none of my code is calling). Looking over the documentation for rts2800_fpu32.lib, and the fact that it mentions that one can compile their own version, my thinking is that the linker is automatically including everything inside the library - regardless of whether or not it is called from the source. This seems like a massive waste, as even with printf-minimal, that's ~6k of functions that I am not calling.

    -Adam

  • Adam Jones said:
    both ___TI_printfi_minimal and _fprintf are inside the compiled file

    That means your code calls fprintf.  Search all of your source code, and header files, for fprintf.

    If that turns up nothing, then here is how to expand the search.  Rebuild everything with --gen_preprocessor_listing.  This generates a preprocessor listing file for every C file.  The file extension changes from .c (or .cpp) to .rl.  Read more about the --gen_preprocessor_listing option in the C2000 compiler manual.  Search all the .rl files for fprintf.  That will show where the call comes from.

    Thanks and regards,

    -George

  • George, well.... after I added that option, both the RAM and FLASH map files showed the fprintf and printfi_minimal were gone. So, I checked by git history, and again, I didn't have the stdio printf before or after. I had even tried renaming -my- printf function to print_f, but both rts objects were still showing up. So, I don't understand what happened, but the space taken up by the RTS library is about 1/3 what it was, with neither printf included.

    Thanks... although, I wish I understood what was actually fixed.