Assembly Technology Insider (5)-EEWORLD

Collect

Experiment with global variables and global constants

Continuing with the previous method, a simple C program is given, in which the declared global variables are divided into three types:
    initialized global variables,
    uninitialized global variables,
    and global constants.
   #vi test5.c

   int i=1;
   int j=2;
   int k=3;
   int l,m;
   int n;
   const int o=7;
   const int p=8;
   const int q=9;
   int main()
   {
       l=4;
       m=5;
       n=6;
       return i+j+k+l+m+n+o+p+q;
   }
   # gcc test5.c -o test5
   # mdb test5
   Loading modules: [ libc.so.1 ]
   > main::dis
   main:             pushl %ebp            ; main to main+1, create Stack Frame
   main+1:           movl   %esp,%ebp
   main+3:           subl   $8,%esp
   main+6:           andl   $0xf0,%esp
   main+ 9:           movl   $0,%eax
   main+0xe:         subl   %eax,%esp        ; main+3 to main+0xe, reserve stack space for local variables and ensure stack 16-byte alignment
   main+0x10:        movl   $4,0x8060948      ; l=4
   main+0x1a:        movl   $5,0x806094c      ; m=5
   main+0x24 :        movl   $6,0x8060950      ; n=6
   main+0x2e:        movl   0x8060908,%eax
   main+0x33:        addl   0x8060904,%eax
   main+0x39:        addl   0x806090c,%eax
   main+0x3f:        addl   0x8060948,%eax
   main+0x45:        addl   0x806094c,%eax
   main+0x4b:        addl   0x8060950,%eax
   main+0x51:        addl   0x8050808,%eax
   main+0x57:        addl   0x805080c,%eax
   main+0x5d:        addl   0x8050810,%eax    ; main+0x2e to main+0x5d, i+j+k+l+m+n+o+ p+q
   main+0x63:        leave                     ; cancel Stack Frame
   main+0x64:        ret                       ; main function returns

   Now, let's set a breakpoint after the global variables are initialized and observe the values of these global variables:
   > main+0x2e:b                                ; Set breakpoint
   > :r                                         ; Run the program
   mdb: stop at main+0x2e
   mdb: target stopped at:
   main+0x2e:     movl   0x8060908,%eax
   > 0x8060904,03/nap                           ; Check the values of global variables i,j,
   ktest5`i:
   test5`i:
   test5`i:       1
   test5`j:       2
   test5`k:       3
   > 0x8060948,03/nap                           ; Check the values of global variables l,m,ntest5`l
   :
   test5`l:
   test5`l:       4
   test5`m:       5
   test5`n:       6
   > 0x8050808,03/nap                           ; Check the values of global variables o,p,qo
   :
   o:
   o:             7
   p:             8
   q:             9
   >

   Concept: Process Address Space

Figure 3-1 Solaris process address space on IA32

As shown in Figure 3-1, the process address space of Solaris on IA32 is similar to that of Linux. Within the 4GB address space of the user process:

   The kernel is always mapped to the top of the user address space, from the macro definition _kernel_base to 0xFFFFFFFF.
   The shared libraries that the user process depends on are followed by the kernel and mapped to the top of the user address
   space. Finally, the user process address space is mapped to the bottom of the address space.

   The code segment of each shared library stores binary executable machine instructions. The kernel maps the code segment of the ELF file of the library to the virtual memory space, and the attribute is read/exec/share. The
   data segment of each shared library stores the global variables required for program execution. The kernel maps the data segment of the ELF file to the virtual memory space, and the attribute is read/write/private.
   The user code segment stores binary executable machine instructions. The kernel maps the code segment of the ELF file to the virtual memory space, and the attribute is read/write/private.
   Above the user code segment is the data segment, which stores the global variables required for program execution. The kernel maps the data segment of the ELF file to the virtual memory space, and the attribute is read/write/private.
   Below the user code segment is the stack, which is the temporary data area of the process. The kernel maps anonymous memory to the virtual memory space, and the attribute is read/write/exec.
   Above the user data segment is the heap, which exists only when malloc is called. The kernel maps anonymous memory to the virtual memory space, and the attribute is read/write/exec.

   Note the differences and connections between Stack and Heap:
   Similarities:
      1. They all come from anonymous memory allocated by the kernel and have nothing to do with the ELF file on the disk.
      2. The attributes are all read/write/exec.
   Differences:
      1. Stack allocation is generally caused by declaring local variables and calling functions at the C language level; heap allocation is caused by explicit calls (malloc)
      2. Stack release is transparent to the user at the C language level, and the user does not need to care about it. The corresponding instructions generated by the C compiler will do it for him; the heap requires an explicit call (free) to release
      3. The growth direction of the stack space is from high address to low address; the growth direction of the heap space is from low address to high address
      4. The stack exists in the address space of any process; the heap does not exist if malloc is not called in the program

The layout of the user address space varies slightly depending on the CPU and OS. The above discussion is based on the situation of X86 CPU on Solaris OS.

Reference address：Assembly Technology Insider (5)

Previous article：Assembly Technology Insider (4)
Next article：Assembly Technology Insider (6)

Popular Resources
Popular amplifiers