1

I needed to look-up the exact byte size of few C functions. Any recommendation of any utility which is able to analyze .obj files generated by the gcc compiler?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
TCSGrad
  • 11,898
  • 14
  • 49
  • 70
  • If you don't find one, you could do the "binary chop", by simply commenting out the code and recompiling, and take a diff on the file size. – Merlyn Morgan-Graham Feb 25 '11 at 04:27
  • 1
    @Merlyn: That could potentially affect all kinds of other dependencies, if the compiler performs dead-code removal of static functions and data (which most do in optimized mode, and measuring anything in debug mode is pretty pointless). – Ben Voigt Feb 25 '11 at 05:31
  • 1
    Some versions of `nm` on some platforms will report the size of objects in an object file. Others (MacOS X, for example) do not. – Jonathan Leffler Feb 25 '11 at 06:14
  • @Jonathan - By size of objects, do you mean C++ objects ? I actually needed C functions size look-up, so was wondering if it'd do the same as well. – TCSGrad Feb 25 '11 at 06:35
  • 1
    Note that modern compilers can merge similar parts of different functions together, or split one function into several non-contiguous chunks of code. I don't know whether GCC does this, but MSVC and ICC do. So keep in mind that doing this universally may be harder than it seems. – atzz Feb 25 '11 at 08:22
  • In the context of my previous remark about 'nm' sometimes returning the sizes of objects, 'objects' means 'things identified in the object (code) file', and that in turn means the sizes of global and file-local (static) variables, and of functions defined in the file. – Jonathan Leffler Feb 25 '11 at 15:13

1 Answers1

5

I only have a GCC v4 here for testing, but I don't think this particular feature of binutils has changed recently.

test.c:

int foo()
{
    return 42;
}

Compiled:

$ gcc -c test.c -o test.o

Disassembled:

$ objdump -D test.o
...
0000000000000000 <foo>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   b8 2a 00 00 00          mov    $0x2a,%eax
   9:   c9                      leaveq
   a:   c3                      retq
...

(We see foo is located at address 0, the size being 0x000b bytes.)

Proof is in the pudding:

$ nm -S test.o
0000000000000000 000000000000000b T foo

At address 0, size 0x000b. There you are. ;-)

However, be careful with what you want to do with these numbers. This is the size of the function allright, but there might be more (e.g. global data objects) required to make the function run correctly.

DevSolar
  • 67,862
  • 21
  • 134
  • 209
  • Though informative, its not the exact answer I was hoping for...but thanks for the info anyway !! – TCSGrad Feb 25 '11 at 09:05
  • 1
    @shan23: Well, *what is your question*? My answer tells about a "utility which is able to analyze .obj files generated by the gcc compiler", telling you "the exact byte size of C functions". If it is not the answer you are looking for, you should think about re-specifying your question. – DevSolar Feb 25 '11 at 09:25
  • It's the exact answer; how is it not what you are hoping for? Please clarify, because I can't give a better answer based on the current question. – MSalters Feb 25 '11 at 09:27
  • MSalters - I realize now, after reading through the entire answer, that the answer is indeed complete. I was a bit confused when it was stated at the end of the objdump example "We see the size is 0x0b bytes" , which I couldn't categorically see in the o/p of objdump - all I was able to see that instructions were from 0-a. Later, I read the example of nm, which exactly points out the starting and ending offsets of foo, the way i initially wanted). Perhaps you could move the example of objdump after nm, to show that nm is indeed right ? Its only a suggestion.... – TCSGrad Feb 25 '11 at 09:47
  • @shan23: I use `objdump` frequently, `nm` only seldom. So I actually *did* call `objdump` first so I knew what value I am looking for in the `nm` output. Since your problem is solved, let's just keep the answer the way it is. Three notes: 1) It's starting offset and *size*, not ending offset. 2) I just noted the comment by Jonathan Leffler that `nm` doesn't work this way on all platforms. 3) *Do* be careful what you use these values for. (I can think of a handful of reasons you could want the size of a function for, and most of them won't work. ;-) ) – DevSolar Feb 25 '11 at 09:57