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:
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:
💡 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“.
💡 see the comments section: you can try using Generated_Code\\*.o Sources\\*.o (double slashes) to have the wildcards working.
I can use relative paths, as at least with the GNU ARM Eclipse plugins the GNU tools have the ‘output’ folder as current directory:
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'
MCUXpresso IDE
In the NXP MCUXpresso IDE this can be added to the Post-Build Steps e.g. like this:
and it gives:
Another way is to use the $(OBJS) macro which lists all objects plus the final binary (ELF) file. The ‘Show totals’ will use the ‘–totals’ option: be careful as this sums up the size of the object files, so it is a kind of worst-case as the linker will remove unused functions and data.
For another way to get this kind of information see “Listing Code and Data Size with GNU nm in Eclipse“.
Summary
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 🙂
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.
LikeLike
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…
LikeLike
if you just use double slashes the wild cards work with KDS.
Generated_Code\\*.o Sources\\*.o
Brynn
LikeLike
Ah, I did not know about that! I have updated the article about this, thank you!
LikeLike
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.
LikeLike
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?
LikeLike
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.
LikeLike
Possible for S08 chips somehow?
LikeLike
Hmm, did not try this, but I would use the decoder.exe for this?
LikeLike
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.
LikeLike
Hi Adam,
that’s a very good idea and way to deal with the object files. I quickly tried that approach, and it works fine :-).
Thanks for sharing,
Erich
LikeLike
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.
LikeLike
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.
LikeLike
Pingback: Listing Code and Data Size with GNU nm in Eclipse | MCU on Eclipse
Pingback: Listing Code and Data Size for all Files with the GNU size Utility in a Post-Build Action | MCU on Eclipse