Listing Code and Data Size for each Source File with GNU and Eclipse

I have used the ‘classic’ CodeWarrior IDE for years, before I moved over to Eclipse some years ago. And as with any IDE or tool switch, things are different in the ‘new world’. In summary, I don’t want to go back anyway, and Eclipse is my development tool of choice now. But from time to time I get challenged about something like “hey, this was possible in the previous tool, so how can I do the same in Eclipse?”. As a fan of Eclipse, this then gets my attention as I feel that Eclipse can do it, and it can do it better. ūüėČ

So what about this one: In CodeWarrior the project view lists code and data size for each source file:

Code And Data Size in CodeWarrior

Code And Data Size in CodeWarrior

CodeWarrior can easily do this, as it maintains an internal data base of the code and details of each compilation unit/file. To me, that feature is nice, but had not much relevance for me, as this does not tell me what will be the code and data size in the application (.elf) file. Because the linker will be smart enough to strip unused functions and data.

Anyway, how to do this in Eclipse and GNU tools? Actually, I have not found a way to show it in a nice view :-(. But I know from my post “Printing Code Size Information in Eclipse” that the ‘size’ utility prints code and data size. But by default only for the application after linking. Which is what I need anyway. But what about listing code and date size for the source files?

My solution is to list the object files as ‘other flags’ the ‘print size’ settings in the project:

Listing object files for GNU Print Size

Listing object files for GNU Print Size

ūüí° With the GNU GCC ARM Embedded (launchpad) 4.8.x it is possible to use wildcards like Sources\*.o. This is not supported in the GNU tools in KDS, as they are using older or different tools, but you can swap the tools chain, see “Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio“.

I can use relative paths, as at least with the GNU ARM Eclipse plugins the GNU tools have the ‘output’ folder as current directory:

Object Files

Object Files

This then lists the size information at the end of the link phase:

'Invoking: Cross ARM GNU Print Size'
arm-none-eabi-size --format=berkeley Sources\Events.o Sources\main.o Generated_Code\Cpu.o Generated_Code\WAIT1.o Generated_Code\IO1.o Generated_Code\CsIO1.o "K64_PEx_Printf.elf"
   text       data        bss        dec        hex    filename
     12          0          0         12          c    Sources\Events.o
    140          0          0        140         8c    Sources\main.o
    108          0          0        108         6c    Generated_Code\Cpu.o
    188          0          0        188         bc    Generated_Code\WAIT1.o
    824          0         24        848        350    Generated_Code\IO1.o
    276          0          0        276        114    Generated_Code\CsIO1.o
  10572        712       8496      19780       4d44    K64_PEx_Printf.elf
'Finished building: K64_PEx_Printf.siz'


It is¬† possible to list the code and data size for each source (well, object) file in Eclipse. I admit it is not in the project view or in a graphical view, and I need to list the object files individually. So I do not say that Eclipse can do the *same*, but I think it is very close ūüėČ

Happy Sizing ūüôā


11 thoughts on “Listing Code and Data Size for each Source File with GNU and Eclipse

  1. Nice idea. I had been looking for the same functionality for a while. Since I was too lazy to list my object files individually, I simply entered:

    Generated_Code\*.o Sources\*.o

    and it lists all the 30+ object file details. Now I just need to find out where the discrepancy between the summed up individual sizes (text+data) and the overall size shown for the *.elf line comes from.


    • Oh wow! I did not think that wildcards would be accepted, so this is a really nice improvement. Thanks for that hint! However, I realize that this trick works with the GNU ARM Embedded (launchpad) 4.8.2, but not with the GNU tools in KDS. Yet another reason to use my own custom tool chain…


  2. It certainly helps having the wildcards support. I’ve since applied this to several projects. It allows analyzing the module sizes right after compiling the project. A time saver! I was missing this from the ‘old’ Codewarrior and usually dug around in the linker map output file for this kind of information whenever the project approached critical mass.

    As to the new KDS: I’ve downloaded but haven’t gotten around to play with it yet. Right now I am using Codewarrior for Microcontrollers Version 10.6 Build 140329 and it works fine there.


  3. Hi,
    How do I open the main.o file. In CW10.5 if I double click it says content cannot be displayed.Do we have to install a plugin kind of a thing for that?


    • Eclipse tries to open files based on the extension with its own viewer. Oterwise it opens the host OS (e.g. Windows) viewer for it. I don’t know why you would try to open the object file in a viewer, as it is a binary file. But if you want to open an ELF object file in a viewer, then you need a plugin or viewer for it. But you might use a disassembler or any kind of ELF/Dwarf viewer with it if you want.


  4. A minor simplification, because the configuration options appear to be based directly to the Makefile, you can just specify:

    Other Flags: $(OBJS)

    This will then get interpreted in the Makefile as the list of object files for that build and doesn’t require lots of messing about if you’ve got deep / exotic hierarchies.

    No idea of how compatible this is with the many possible ways of using Eclipse (versions, etc..), works for me with GNU ARM setup.


      • Also I think you were commenting on the difference between the summed files and the final object. This is due to a variety of factors, probably mostly due to removed functions (at linker time) and missing library code that is in the final binary but you don’t have local files to pass to the analysis. Also the way in which the various numbers are reported creates some minor discrepancies which can be worked through with a bit of analysis of the map file.

        I’ve got a script on my laptop at work that processes the map file and gives an object by object report which “nearly” matches the final binary. There is a discrepancy as I missed the word alignment padding before the STACK.


      • Yes, things removed by the linker afterwards will have an impact on the reported size. And there might be some differences because of alignment or other allocation factors too.


What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s