how objdump handles global variables - objdump

Question

I have made the following dummy code for testing
/tmp/test.c contains the following:
#include "test.h"
#include <stdio.h>
#include <stdlib.h>
struct s* p;
unsigned char *c;
void main(int argc, char ** argv) {
memset(c, 0, 10);
p->a = 10;
p->b = 20;
}
/tmp/test.h contains the following:
struct s {
int a;
int b;
};
I compile and run objdump as follows:
cd /tmp
gcc -c test.c -o test.o
objdump -gdsMIntel test.o
I get the following output:
test.o: file format elf32-i386
Contents of section .text:
0000 5589e5a1 00000000 c7000000 0000c740 U..............#
0010 04000000 0066c740 080000a1 00000000 .....f.#........
0020 c7000a00 0000a100 000000c7 40041400 ............#...
0030 00005dc3 ..].
Contents of section .comment:
0000 00474343 3a202855 62756e74 752f4c69 .GCC: (Ubuntu/Li
0010 6e61726f 20342e36 2e332d31 7562756e naro 4.6.3-1ubun
0020 74753529 20342e36 2e3300 tu5) 4.6.3.
Contents of section .eh_frame:
0000 14000000 00000000 017a5200 017c0801 .........zR..|..
0010 1b0c0404 88010000 1c000000 1c000000 ................
0020 00000000 34000000 00410e08 8502420d ....4....A....B.
0030 05700c04 04c50000 .p......
Disassembly of section .text:
00000000 <main>:
0: 55 push ebp
1: 89 e5 mov ebp,esp
3: a1 00 00 00 00 mov eax,ds:0x0 ;;;; should be the address of unsigned char *c
8: c7 00 00 00 00 00 mov DWORD PTR [eax],0x0 ;;;; setting 10 bytes to 0
e: c7 40 04 00 00 00 00 mov DWORD PTR [eax+0x4],0x0
15: 66 c7 40 08 00 00 mov WORD PTR [eax+0x8],0x0
1b: a1 00 00 00 00 mov eax,ds:0x0
20: c7 00 0a 00 00 00 mov DWORD PTR [eax],0xa ;;;; p->a = 10;
26: a1 00 00 00 00 mov eax,ds:0x0
2b: c7 40 04 14 00 00 00 mov DWORD PTR [eax+0x4],0x14 ;;;; p->b = 20;
32: 5d pop ebp
33: c3 ret
In the above disassembly, I find that:
In the case of c, the following is done:
mov eax, ds:0x0
mov DWORD PTR [eax], 0
In the case of p->a the following is done:
mov eax, ds:0x0
mov DWORD PTR [eax],0x0
In that case, are both c and p->a located in the same address (ds:0x0)?

Answer 1

The .o file is not yet executable, there'll be relocation entries pointing to those 0's which the linker will fixup later. Since your source file seems mostly self-contained, can you drop the -c flag to produce an (fully linked) executable rather than a relocatable object file?