On most modern uniprocessors memory operations are not executed in the order specified by the program code. In single threaded programs all operations appear to have been executed in the order specified, with all out-of-order execution hidden to the programmer – however in multi-threaded environments (or when interfacing with other hardware via memory buses) this can lead to problems. To avoid problems, memory barriers can be used in these cases.
So far, we've discussed C Pointers and Arrays, C Character Pointer and String Manipulation. There are very confusingly named concepts and it's very easy to get them mixed up.
In this article, we'll see what happens when an external reference is declared with the wrong but compatible type. There are two cases involved, refer array as pointer and opposite.
在上一篇 ARM64 Memory Ordering - re-ordering 中，我们介绍了编译器编译时和 CPU 执行时，可能为了提高并行效率，会将指令重排乱序执行。本篇梳理了不同的内存模型下，多处理器并发竞争访问存储器时，指令重排乱序执行可能导致的结果非预期风险。
特别地，在 ARM64 实现的典型的弱一致性内存模型下，程序可能需要添加适当的同步操作来避免竞争访问以保障读写次序。这里说的“同步操作”指的是内存屏障指令，它是系统编程中很重要的一部分，特别是在多核并行编程中。
The ARMv8 architecture defines two mutually-exclusive memory types. All regions of memory are configured as one or the other of these two types, which are Normal and Device. A third memory type, Strongly Ordered, is part of the ARMv7 architecture. The differences between this type and Device memory are few and it is therefore now omitted in ARMv8.
In addition to the memory type, attributes also provide control over cacheability, shareability, access, and execution permissions. Shareable and cache properties pertain only to Normal memory. Device regions are always deemed to be non-cacheable and outer-shareable. For cacheable locations, you can use attributes to indicate cache allocation policy to the processor.
In C program, a "string" is a null-terminated array of char. To be more precise, it's an array of characters terminated with a '\0' to mark the end.
C doesn't provide any operators for processing an entire string of characters as a unit, only arrays and pointers are involved.
Early implementations of the ARM architecture such as the ARM7TDMI executed all instructions in program order. Each instruction was fully executed before the next instruction was started.
Newer processors employ a number of optimizations that relate to the order in which instructions are executed and the way memory accesses are performed.
Many beginners don't know about the relationship between pointers and arrays. I'll tell you now: there is no relationship between them, they just often wear similar clothes to tease you. A pointer is a pointer. A pointer variable occupies 4 bytes in a 32-bit system and 8 bytes in a 64-bit system. Its value is the address of a particular memory location. A pointer can point to anything, but can you access anything using this pointer variable?
An array is an array, and its size is related to the type and number of its elements; when defining an array, the type and number of its elements must be specified; an array can hold any kind of data, but not functions. Since there is no relationship between them, why do many people often confuse arrays with pointers, and even think that pointers and arrays are the same?
This is related to the mixed C language reference books on the market. Few books explain this topic thoroughly and clearly. Let's go back to the classics, back to the basics, and get the truth from the classic explanations and interpretations of the masters.
A C program, whatever its size, consists of functions and variables. A function contains statements that specify the computing operations to be done, and variables store values used during the computation.
Every time we want to use a variable(e.g. char c; int i;), we must declare it in advance, which actually allocates a space in memory with the width corresponding to the variable type.
A pointer is a variable that contains the address of another variable.
Nearly every introduction to exploitation covers Aleph One's classic article "Smashing the Stack for Fun and Profit"(pdf1, pdf2), which explains the basics of exploiting stack-based buffer overflows.
In this article, I'll explore the basic Buffer overflow protection mechanism based on stack canary.
So far, we've combed through the basics - expr, a module - analysis and i/p modules - info/print.
In this article, I'll give an overview of the d and v modules:
d: Debugging module is dedicated to dynamic analysis. Support viewing registers, setting breakpoints, controlling program running process(continue, step), etc.v: Visual mode is a user-friendly alternative to the command line that offers a variety of visualization features.