1. privileged and user mode from ARM Architecture Manual ARMv7-A and ARMv7-R edition
"A3.6.1 Processor privilege levels, execution privilege, and access privilege
As introduced in About the Application level programmers’ model on page A2-38, within a security state, the ARMv7 architecture defines different levels of execution privilege:
• in Secure state, the privilege levels are PL1 and PL0
• in Non-secure state, the privilege levels are PL2, PL1, and PL0.
PL0 indicates unprivileged execution in the current security state.
The current processor mode determines the execution privilege level, and therefore the execution privilege level can be described as the processor privilege level.
Every memory access has an access privilege, that is either unprivileged or privileged.
The characteristics of the privilege levels are:
1) PL0 The privilege level of application software, that executes in User mode. Therefore, software
executed in User mode is described as unprivileged software. This software cannot access some
features of the architecture. In particular, it cannot change many of the configuration settings.
Software executing at PL0 makes only unprivileged memory accesses.
2) PL1 Software execution in all modes other than User mode and Hyp mode is at PL1. Normally, operating system software executes at PL1. Software executing at PL1 can access all features of the
architecture, and can change the configuration settings for those features, except for some features
added by the Virtualization Extensions that are only accessible at PL2.
Note In many implementation models, system software is unaware of the PL2 level of privilege, and of
whether the implementation includes the Virtualization Extensions.
The PL1 modes refers to all the modes other than User mode and Hyp mode.
Software executing at PL1 makes privileged memory accesses by default, but can also make
unprivileged accesses.
3) PL2 Software executing in Hyp mode executes at PL2.
Software executing at PL2 can perform all of the operations accessible at PL1, and can access some
additional functionality.
Hyp mode is normally used by a hypervisor, that controls, and can switch between, Guest OSs, that
execute at PL1.
2. run-time initialization of c program
8.11.1 Run-Time Initialization from TI Assembly Guide
"All C/C++ programs must be linked with code to initialize and execute the program, called a bootstrap routine, also known as the boot.obj object module. The symbol _c_int00 is defined as the program entry point and is the start of the C boot routine in boot.obj; referencing _c_int00 ensures that boot.obj is automatically linked in from the run-time-support library. When a program begins running, it executes boot.obj first. The boot.obj symbol contains code and data for initializing the run-time environment and performs the following tasks:
• Changes from system mode to user mode
• Sets up the user mode stack
• Processes the run-time .cinit initialization table and autoinitializes global variables (when the linker is invoked with the --rom_model option)
• Calls main
The run-time-support object libraries contain boot.obj. You can:
• Use the archiver to extract boot.obj from the library and then link the module in directly.
• Include the appropriate run-time-support library as an input file (the linker automatically extracts
boot.obj when you use the --ram_model or --rom_model option)."
3. stack - регистр R13 (SP)
6.1.2 C/C++ System Stack from ARM Optmizing C/C++ Compiler
"The run-time stack grows from the high addresses to the low addresses. The compiler uses the R13 register to manage this stack. R13 is the stack pointer (SP), which points to the next unused location on the stack.
The linker sets the stack size, creates a global symbol, __TI_STACK_SIZE, and assigns it a value equal to the stack size in bytes. The default stack size is 2048 bytes. You can change the stack size at link time by using the --stack_size option with the linker command. For more information on the --stack_size option, see the linker description chapter in the ARM Assembly Language Tools User's Guide.
At system initialization, SP is set to a designated address for the top of the stack. This address is the first location past the end of the .stack section. Since the position of the stack depends on where the .stack section is allocated, the actual address of the stack is determined at link time.
The C/C++ environment automatically decrements SP at the entry to a function to reserve all the space
necessary for the execution of that function. The stack pointer is incremented at the exit of the function to restore the stack to the state before the function was entered. If you interface assembly language routines to C/C++ programs, be sure to restore the stack pointer to the same state it was in before the function was entered."
Links:
4. heap
6.1.3 Dynamic Memory Allocation from ARM Optmizing C/C++ Compiler
"The run-time-support library supplied with the ARM compiler contains several functions (such as malloc, calloc, and realloc) that allow you to allocate memory dynamically for variables at run time.
Memory is allocated from a global pool, or heap, that is defined in the .sysmem section. You can set the size of the .sysmem section by using the --heap_size=size option with the linker command. The linker also creates a global symbol, __TI_SYSMEM_SIZE, and assigns it a value equal to the size of the heap in bytes. The default size is 2048 bytes. For more information on the --heap_size option, see the linker description chapter in the ARM Assembly Language Tools User's Guide.
If you use any C I/O function, the RTS library allocates an I/O buffer for each file you access. This buffer will be a bit larger than BUFSIZ, which is defined in stdio.h and defaults to 256. Make sure you allocate a heap large enough for these buffers or use setvbuf to change the buffer to a statically-allocated buffer.
Dynamically allocated objects are not addressed directly (they are always accessed with pointers) and the memory pool is in a separate section (.sysmem). Therefore, the dynamic memory pool size may be limited only by the amount of memory in your system. To conserve space in the .bss section, you can allocate large arrays from the heap instead of defining them as global or static. For example, instead of a definition such as:
struct big table[100];Use a pointer and call the malloc function:
struct big *tabletable = (struct big *)malloc(100*sizeof(struct big));
When allocating from a heap, make sure the size of the heap is large enough for the allocation. This is particularly important when allocating variable-length arrays."
Links:
