As a homework question, I was told to use objdump -d on a compiled object on two separate computers, and explain whether the code was fixed or variable length on each.
I think the code is fixed length, but I'm not quite sure... here's a short excerpt from it:
That's fixed length, right? Each instruction is just 32 bits (the 8 hex digits in the middle, right?)
Most of the code looks the same until the very end when I have this:
The first several lines appear to be 128-bits (32 hex digits) each and then the last line is 64-bits (16 hex digits)... does this mean that not all of my instructions are the same length, or do these not count as instructions? If these aren't instructions, what are they?
Next question I have... I ran otool on my iMac with -tV to disassemble a few different object files and I noticed that all of them start with this:
Regardless of optimization levels and what the C program consisted of, it seems to always output this at the very start. Can anyone explain to me what this is? (Also, is there anyway I can make it so otool includes the bytes in hex alongside the assembly code the way objdump -d does? I've found objdump itself doesn't seem to be preinstalled on Macs as it is on Linux and Unix so I've been using otool instead...
I think the code is fixed length, but I'm not quite sure... here's a short excerpt from it:
Code:
107d8: bc 10 20 00 clr %fp
107dc: e0 03 a0 40 ld [ %sp + 0x40 ], %l0
107e0: a2 03 a0 44 add %sp, 0x44, %l1
107e4: 9c 23 a0 20 sub %sp, 0x20, %sp
107e8: 80 90 00 01 tst %g1
107ec: 02 80 00 04 be 107fc <_start+0x24>
107f0: 90 10 00 01 mov %g1, %o0
107f4: 40 00 42 a4 call 21284 <_PROCEDURE_LINKAGE_TABLE_+0x30>
107f8: 01 00 00 00 nop
107fc: 11 00 00 44 sethi %hi(0x11000), %o0
10800: 90 12 21 70 or %o0, 0x170, %o0 ! 11170 <_fini>
10804: 40 00 42 a0 call 21284 <_PROCEDURE_LINKAGE_TABLE_+0x30>
10808: 01 00 00 00 nop
1080c: 40 00 02 52 call 11154 <_init>
10810: 01 00 00 00 nop
10814: 90 10 00 10 mov %l0, %o0
10818: 92 10 00 11 mov %l1, %o1
1081c: 95 2c 20 02 sll %l0, 2, %o2
10820: 94 02 a0 04 add %o2, 4, %o2
10824: 94 04 40 0a add %l1, %o2, %o2
10828: 17 00 00 8f sethi %hi(0x23c00), %o3
1082c: 96 12 e1 88 or %o3, 0x188, %o3 ! 23d88 <_environ>
10830: d4 22 c0 00 st %o2, [ %o3 ]
10834: 40 00 02 2c call 110e4 <main>
10838: 01 00 00 00 nop
1083c: 40 00 42 95 call 21290 <_PROCEDURE_LINKAGE_TABLE_+0x3c>
10840: 01 00 00 00 nop
10844: 40 00 42 96 call 2129c <_PROCEDURE_LINKAGE_TABLE_+0x48>
10848: 01 00 00 00 nop
1084c: 81 c3 e0 08 retl
10850: ae 03 c0 17 add %o7, %l7, %l7
That's fixed length, right? Each instruction is just 32 bits (the 8 hex digits in the middle, right?)
Most of the code looks the same until the very end when I have this:
Code:
00021254 <_PROCEDURE_LINKAGE_TABLE_>:
...
21284: 03 00 00 30 30 bf ff f3 01 00 00 00 03 00 00 3c ...00..........<
21294: 30 bf ff f0 01 00 00 00 03 00 00 48 30 bf ff ed 0..........H0...
212a4: 01 00 00 00 03 00 00 54 30 bf ff ea 01 00 00 00 .......T0.......
212b4: 03 00 00 60 30 bf ff e7 01 00 00 00 03 00 00 6c ...`0..........l
212c4: 30 bf ff e4 01 00 00 00 03 00 00 78 30 bf ff e1 0..........x0...
212d4: 01 00 00 00 03 00 00 84 30 bf ff de 01 00 00 00 ........0.......
212e4: 03 00 00 90 30 bf ff db 01 00 00 00 03 00 00 9c ....0...........
212f4: 30 bf ff d8 01 00 00 00 03 00 00 a8 30 bf ff d5 0...........0...
21304: 01 00 00 00 01 00 00 00 ........
The first several lines appear to be 128-bits (32 hex digits) each and then the last line is 64-bits (16 hex digits)... does this mean that not all of my instructions are the same length, or do these not count as instructions? If these aren't instructions, what are they?
Next question I have... I ran otool on my iMac with -tV to disassemble a few different object files and I noticed that all of them start with this:
Code:
start:
pushq $0x00
movq %rsp,%rbp
andq $0xf0,%rsp
movq 0x08(%rbp),%rdi
leaq 0x10(%rbp),%rsi
movl %edi,%edx
addl $0x01,%edx
shll $0x03,%edx
addq %rsi,%rdx
movq %rdx,%rcx
jmp 0x100000f15
addq $0x08,%rcx
cmpq $0x00,(%rcx)
jne 0x100000f11
addq $0x08,%rcx
callq 0x100000f30
movl %eax,%edi
callq 0x100000f38
hlt
nop
nop
nop
nop
Regardless of optimization levels and what the C program consisted of, it seems to always output this at the very start. Can anyone explain to me what this is? (Also, is there anyway I can make it so otool includes the bytes in hex alongside the assembly code the way objdump -d does? I've found objdump itself doesn't seem to be preinstalled on Macs as it is on Linux and Unix so I've been using otool instead...