ARM linux: Process address space - linux-kernel

Question

I'm using a development board(snowball) with an ARM cortex_A9_MPCORE processor, running linux with a 3.0.8+ kernel.
I use GDB and openocd for debuging.
I'm looking for a way to find the address space of a user mode process, especially the text segment and the user mode stack.
first I looked into /proc/"PID"/maps, for example I'm getting this output for one of the processes running:
# cat /proc/1124/maps
00008000-000d5000 r-xp 00000000 b3:02 181 /system/bin/lbsd
000d5000-000f8000 rw-p 000cd000 b3:02 181 /system/bin/lbsd
000f8000-0014a000 rw-p 00000000 00:00 0 [heap]
0014a000-0014c000 rw-p 00000000 00:00 0 [heap]
.
.
.
b0001000-b0009000 r-xp 00001000 b3:02 183 /system/bin/linker
b0009000-b000a000 rw-p 00009000 b3:02 183 /system/bin/linker
b000a000-b0015000 rw-p 00000000 00:00 0
bea00000-bea21000 rw-p 00000000 00:00 0 [stack]
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]
Then using GDB I wrote a script that parses the list of taskes running on the board, starting from init_task, for each task it gets the value of the mm_struct found in task_struct then extracts the values of start_code, end_code and start_stack. Finally the script parses the different memory areas pointed by mmap.
The script runs while the board is in debug state, both cores of the cortex a9 are halted
Here is the output of the GDB scripts for the same process as above:
taskaddr 0xdf29f140
Name: lbsd
mm start text 8000
mm end text d4ba4
mm start stack bee63df0
####MEMORY REGIONS#####
vm_start 0x8000
vm_end 0xd5000
vm_flags 0x8001875
-----------------------
vm_start 0xd5000
vm_end 0xf8000
vm_flags 0x8101873
-----------------------
vm_start 0xf8000
vm_end 0x14a000
vm_flags 0x100073
-----------------------
vm_start 0x14a000
vm_end 0x14c000
vm_flags 0x100073
-----------------------
.
.
.
-----------------------
vm_start 0xb0001000
vm_end 0xb0009000
vm_flags 0x8000875
-----------------------
vm_start 0xb0009000
vm_end 0xb000a000
vm_flags 0x8100873
-----------------------
vm_start 0xb000a000
vm_end 0xb0015000
vm_flags 0x100073
-----------------------
vm_start 0xbee42000
vm_end 0xbee64000
vm_flags 0x100173
-----------------------
vm_start 0xffff0000
vm_end 0xffff1000
vm_flags 0x40c0055
-----------------------
The memory regions match for both the method used except for the stack, in the output of the /proc method it starts at bea00000 while in the start_stack field of the mm_struct it's at bee63df0, and the memory region pointed by vm_struct indicates bee42000.
Can someone please explain the difference in these values?
My second question is about the values of the first memory region between 00008000 and 000d5000 which corresponds to the text section of the process. I noticed that a lot of process share those addresses. How does the kernel manage to get the real address of the text memory region?

Answer 1

On ARM, the stack grows down. This means the stack starts at higher addresses. This is visible in the vm_flags for the stack vma, which has the VM_GROWSDOWN bit set.
The stack vma has a vm_end of 0xbee64000, which is exactly 528 bytes higher than the start_stack of 0xbee63df0. This happens because there are a few things above the top of the stack in the same VMA: the command line, the environment, and the auxiliary vectors.
I do not know why the stack (and only it) is at a different address at /proc/<pid>/maps. Looking at the kernel source code, I see a vma can be shown as [stack] if and only if start_stack is within it, so if the start_stack was the same when you looked at /proc/<pid>/maps, that vma could not have been marked as [stack]. The only explanation I can think of is that it is from a different run of your executable, and that the address layout randomization is disabled for everything but the stack.
Now the second question.
While your process is running, the hardware uses page tables to map from a virtual address (for instance 0x8000) to the physical address of the page. The kernel can do the same; it has a pointer to the root page tables (pgd) for a process in its mm_struct. Once it has the physical page number (pfn), it can get to the corresponding struct page. There is a large set of macros and functions to do all these manipulations.
But a page might be missing. For instance, one of the pages of your executable might not have been faulted in yet. The entry for that page in the page tables will show it as missing. The kernel then looks at the corresponding vma, which given an offset within the vma has enough information to get the page from somewhere, and insert it within the page tables.