2
793 00010cfc <main>:
    794    10cfc:       e92d4800        push    {fp, lr}
    795    10d00:       e28db004        add     fp, sp, #4
    796    10d04:       e24dd008        sub     sp, sp, #8
    797    10d08:       e3a03000        mov     r3, #0
    798    10d0c:       e50b3008        str     r3, [fp, #-8]
    799    10d10:       e51b3008        ldr     r3, [fp, #-8]
    800    10d14:       e2833001        add     r3, r3, #1
    801    10d18:       e50b3008        str     r3, [fp, #-8]
    802    10d1c:       e59f3040        ldr     r3, [pc, #64]   ; 10d64 
    <main+0x68>
    803    10d20:       e5933000        ldr     r3, [r3]
    804    10d24:       e51b2008        ldr     r2, [fp, #-8]
    805    10d28:       e0823003        add     r3, r2, r3
    806    10d2c:       e50b3008        str     r3, [fp, #-8]
    807    10d30:       e59f3030        ldr     r3, [pc, #48]   ; 10d68 
    <main+0x6c>
    808    10d34:       e3a02014        mov     r2, #20
    809    10d38:       e5832000        str     r2, [r3]
    810    10d3c:       e59f3028        ldr     r3, [pc, #40]   ; 10d6c 
    <main+0x70>
    811    10d40:       e3a0201e        mov     r2, #30
    812    10d44:       e5832000        str     r2, [r3]
    813    10d48:       e59f0020        ldr     r0, [pc, #32]   ; 10d70 
    <main+0x74>
    814    10d4c:       e51b1008        ldr     r1, [fp, #-8]
    815    10d50:       eb001917        bl      171b4 <_IO_printf>
    816    10d54:       e3a03000        mov     r3, #0
    817    10d58:       e1a00003        mov     r0, r3
    818    10d5c:       e24bd004        sub     sp, fp, #4
    819    10d60:       e8bd8800        pop     {fp, pc}
    820    10d64:       00097568        .word   0x00097568
    821    10d68:       000991b0        .word   0x000991b0
    822    10d6c:       000983f4        .word   0x000983f4
    823    10d70:       00070944        .word   0x00070944

I want to focus on line 802 and 820. when I objdump -d ./program, there is .word. It looks like that refers to the address of some words but there is no such address like 0x00097568 in my executable object file. when I use gdb, it does some operation like below

0x00010d64 <+104>:   andeq   r7, r9, r8, ror #10

So, I guess 0x00097568 is come from that operation but what does 0x00097568 mean?

Note that I gave -static option when I made the executable object file.

Here is my program.c code

 1 #include <stdio.h>
 2 int val1=10;
 3 int val2;
 4 static val3;
 5
 6 int main() {
 7   int a=0;
 8   a=a+1;
 9   a=a+val1;
10
11   val2=20;
12   val3=30;
13
14   printf("a : %d\n",a);
15   return 0;
16
17 }
ndim
  • 35,870
  • 12
  • 47
  • 57
doosolLee
  • 43
  • 7

1 Answers1

0

objdump does not recognize that part of the binary content you are disassembling as an instruction and it just displays it as if it were a 32-bit data chunk:

00097568        .word   0x00097568

That is what .word means. You can see that the value on the right side (the one displayed with .word) is the same as the one on the left side (the binary encoding): 0x00097568

JFMR
  • 23,265
  • 4
  • 52
  • 76
  • thanks for answer! i checked what does 'address 00097568' contain by 'objdump -Dslx'. Now i know 00097568 is address in .data section. but i still don't know why do they do ' andeq r7, r9, r8, ror #10 ' to obtain 00097568. Do gcc compiler choose global variable address by andeq? is it a mechanism? – doosolLee Aug 06 '17 at 08:12
  • 1
    @doosol-Lee no, values in computer are encoded in bits (0 and 1). A "word" is 32 bits, and it is basic working size of value in ARM CPU. The instructions are stored as 32 bit values too, in memory (single instruction = 1 word, as ARM is RISC-like with fixed instruction size architecture). So you can define any random 32 bit value in memory, and if you will force disassembler to disassemble it, it will produce very likely some valid instruction, like in this case the `gcc` did need value `00097568` to point into `.data` segment, calculating it as an address, not aware of `andeq` produced. – Ped7g Aug 06 '17 at 08:31
  • @doosol-Lee you may also check the soon to be removed docs here [machine code](https://stackoverflow.com/documentation/assembly/1358/getting-started-with-assembly-language/8901/machine-code#t=201708060832436519976), maybe it will make more sense. BTW, you may ask why gcc did need that value in memory as word, and it surprisingly relates to the comment above. As you have only 32 bits for instruction encoding, you can't encode `registerX = 32bit value;` in single word (the value would occupy all bits, no bits left for instruction opcode). On ARM the compiler then often loads value from memory. – Ped7g Aug 06 '17 at 08:35
  • It isn't that objdump “doesn't recognize” this. As far as I know, the ELF variant for ARM has a special debug section telling the disassembler which words are instructions and which are part of a literal pool. You can verify this by assembling a fiile with `.word 0xe92d4800` which corresponds to `push {fp, lr}` but is still printed as `.word e92d4800` due to this special debug data. – fuz Aug 06 '17 at 10:35
  • @fuz My objdump has some of the code (which I know to be Thumb-2 instructions) displayed as data and not being disassembled. Most of the code gets properly recognized as instructions, but not all of it for some reason. Even more strange, the dump contains inlined C code interleaved with these ".word". So objdump does't seem to know these are instructions, yet is able to make it correspond with C code? – jeremfg Dec 10 '19 at 22:13
  • 1
    @jeremfg Do not post comments under other people's questions to ask your own questions. Instead, please make a new question. – fuz Dec 10 '19 at 22:36