Post navigation

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

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:

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 😉

About Erich Styger

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

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…

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.

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.

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.