3

So in a 32bit environment i compile a ".c" file. 

       A.c and get A.o

I save A.o .

Suppose A.c has a variable like 

     int a // i change this to long a;

After the change i compile and get another A.o.

Now when i do " cmp A.o A.o " , i can see that these files differ. Now my question can i find out what exactly changed by comparing ".o" files.

I am getting the assembly code out and doing a diff, but i cant make head and tails of it. Can someone suggest a smarter way.

Rags
  • 434
  • 2
  • 6
  • 20
  • 1
    The smarter way is to diff the source, not the object files :-) Seriously, comparing object files is going to be extremely hard if you don't know assembly very well. Some small changes in source might generate drastic changes in the object code. Other changes might not change the object code at all. The same code can generate different object files with very slight changes in the environment. – Mat Nov 25 '13 at 20:25
  • `.o` files would be gibberish. They are already translated to the target microcontroller's machine code. – Fiddling Bits Nov 25 '13 at 20:26
  • WHY are you doing this? – n. m. could be an AI Nov 25 '13 at 20:29
  • Yes i understand that comparing source files is a better way. So my intend was that , after i have done my porting to 64bit build , i wanted to check if the 32build functionality still works . So if compare .o files and if they have not changed that means 32bit will work perfectly. Just a way of testing i think.. – Rags Nov 25 '13 at 20:32
  • If you compile on a 64 bit architecture it is obvious that the object files will be different. It is the compiler which ensures you that the functionality is preserverd across different builds. – Paul92 Nov 25 '13 at 20:37
  • after i port i compile for both 64bit and 32bit build. Obviously 64bit build will have different object files bit 32bit build should have same object file if i am not wrong. – Rags Nov 25 '13 at 20:39
  • is just testing both not an option or something? – Kevin Nov 25 '13 at 21:38

1 Answers1

4

I try to answer to this question. Object files can be compared directly with a binary hex editor. What you obtain in this way is not human readable as an object file is mostly machine code (it has also symbols for the linker when it's not yet linked). I find this method useful only to check little things (like code version and build date for firmwares). I think that an understanding of significant changes can only be achieved disassembling the object file. Fortunately there are tools around that do this job like objdump for linux and for unix, assembler is not straightforward sometimes but at least it is human readable. Assuming that you are using a linux machine you can run the following command:

objdump -d yourobjectfile1 > out1
objdump -d yourobjectfile2 > out2

and than compare the results. You will discover that a little change in the c code can result in a big readjustment of the assembly code, so as for an experiment I suggest you to work with something of the level of helloworld.c

Other suggestions

  1. Compile with -O0, it creates an easier assembly (and more similar to your c) as optimizations are disabled.
  2. Try with an executable or linked shared library (only machine code) and strip your object before comparing, in this way you will reduce its size.
  3. You can create a mixed c-assembler code that can make the reading easier in this way:gcc -g -c -fverbose-asm myfile.c; objdump -d -M intel -S ass.o > main.s

List item

Jekyll
  • 1,434
  • 11
  • 13