2

Given the following program:

unsigned char g1[] = { 0x1a, 0x2a, 0x3a, 0x4a };
static unsigned char g2[] = { 0x1b, 0x2b, 0x3b, 0x4b };

int main()
{
  unsigned char l1[] = { 0x1c, 0x2c, 0x3c, 0x4c };
  static unsigned char l2[] = { 0x1d, 0x2d, 0x3d, 0x4d };
}

After, compiling it simply with "g++ test.cpp -o test" and running hexdump -C on the binary, I realized that the sequences for g1, g2 and l2 can be found clearly on the binary. Only the sequence for l1 (1c 2c 3c 4c) it apparently not present anywhere in the binary file.

Would anyone know why that is?

unwind
  • 391,730
  • 64
  • 469
  • 606

3 Answers3

4

Because it is allocated on the stack of that function call. Typically in cases like this, one of two things will happn:

  1. The compiler will store that sequence in the data section, and then essentially memcpy it into the stack buffer.

  2. The compiler essentially hard-codes "move" instructions to re-assemble the sequence from the largest immediate value of the instruction set (often a 4-bye int).

If it was not optimized out, like "unwind" mentioned, then #2 is probably happening. Looking at the disassembly the proprogram (or the pre-assembled asm code) would show you better. Use -S and look at the .s files.

Jonathon Reinhart
  • 132,704
  • 33
  • 254
  • 328
3

My guess would be since it's non-static and automatic (non-global), it's trivial to know that nobody will be able to reference it from the outside. Since it's not being used, it can be dropped.

unwind
  • 391,730
  • 64
  • 469
  • 606
0

l1[] and l2[] are removed during compiler optimisation because both are local and unused variables (no chance that both variable will be use any where else).

you can compile your code with -S option to generate assembly code: and there is no definition for l1[] and l2[] in main not even any where else:

input file was x.c, compiled with command gcc -S x.c to generate assembly file x.s

main:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $16, %esp
    movb    $28, -4(%ebp)
    movb    $44, -3(%ebp)
    movb    $60, -2(%ebp)
    movb    $76, -1(%ebp)
    leave
    ret
    .size   main, .-main
    .data
    .type   l2.1250, @object
    .size   l2.1250, 4

But you can find definition for g1[] and g2[].

    .file   "x.c"
.globl g1
    .data
    .type   g1, @object
    .size   g1, 4
g1:
    .byte   26
    .byte   42
    .byte   58
    .byte   74
    .type   g2, @object
    .size   g2, 4
g2:
    .byte   27
    .byte   43
    .byte   59
    .byte   75
    .text
.globl main
    .type   main, @function  

Additionally , It would be interesting to know if you compile if you compile you code with flag -O3 optimisation flag level 3 then only definition of g1[] is present. and global static variables(private to the file) are also removed.

input file was x.c, compiled with command gcc -S -O3 x.c to generate assembly file x.s

below:

    .file   "x.c"
    .text
    .p2align 4,,15
.globl main
    .type   main, @function
main:
    pushl   %ebp
    movl    %esp, %ebp
    popl    %ebp
    ret
    .size   main, .-main
.globl g1
    .data
    .type   g1, @object
    .size   g1, 4
g1:
    .byte   26
    .byte   42
    .byte   58
    .byte   74
    .ident  "GCC: (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5"
    .section    .note.GNU-stack,"",@progbits  

g1[] is global data only present, and g2[] is removed in -O3.

g2[] use defined static unsigned char g2[] so access only within this file and not use so again unused. But g1[] is global it may be useful by other program if other file include it this. And compiler is not allowed to optimisation away global objects.

Reference: How do I prevent my 'unused' global variables being compiled out?

So, this all due to compiler optimisation!

Community
  • 1
  • 1
Grijesh Chauhan
  • 57,103
  • 20
  • 141
  • 208
  • I guess you may find some more details here [**Coding Practices which enable the compiler/optimizer to make a faster program**](http://stackoverflow.com/questions/2074099/coding-practices-which-enable-the-compiler-optimizer-to-make-a-faster-program) But I am not sure. I didn't read it. – Grijesh Chauhan Jan 16 '13 at 13:53