Assembly Questions (HW)

[ArtOfWarfare]

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:

   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:

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:

 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...

[ghellquist]

The give-away is this line:
call 21284 <_PROCEDURE_LINKAGE_TABLE_+0x30>

The program here makes a call to something that looks and sounds like a table. Why?

Because it is a table of adresses.

The reason probably is that the table is filled by the linker. Remember, a program often is created in modules that are compiled separately and then linked together. The linker does work in mysterious ways, one of them is to change calls by name into the exact adress where the code is stored.

// Gunnar

[ElectricSheep]

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:

 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...

This is the C runtime library, or crt0.o. Yes, even C has a runtime library. Its very lightweight, and its only job is to set up the stack and frame pointers, perform any necessary initializations, call main(), and then call exit() with the return code from main().

[ArtOfWarfare]

Originally Posted by ElectricSheep

This is the C runtime library, or crt0.o. Yes, even C has a runtime library. Its very lightweight, and its only job is to set up the stack and frame pointers, perform any necessary initializations, call main(), and then call exit() with the return code from main().

Very interesting; thank you for sharing!