Nice to meet you guys, I am Rafael. If you like to learn more about me, come here!
I have put this note in my draft for a long time 😜 Recently, got a chance again to play with it in research. Here is the story about playing Angr just like a baby. Constraint solving with Z3 Before we look into Angr, we should be faimiliar with Z3 first. 1 2 3 4 5 6 7 8 9 10 x = int(argv) y = iny(argv) z = x + y if(x >= 5) y = y + z if(y < x) foobar(x, y, z) else .
Before this article, concept about lexical analysis is prerequisite. Here is the door about my previous article. Then, I would follow the prev article to implement the scanner part for Lox. Scanner One important point is that our scanner will read the source code as a very long^3 string. e.g., different lines of source code would only become the concatenation of strings and \n. Before we go to the core implementation of scanner, of course we need to define the token type first.
Start following the book of CRAFTING INTERPRETERS in this series. Book always includes large number of information and context. Hope this series of reading notes can help me to review easily in some days. CRAFTING is implementation, I hope I can build up an interpreter with this series. In this book, two interpreters will be created: jlox in Java and clox in C. The programming language to be implemented is Lox (self-defined).
In prev article, we already know how ELF is loaded into memory and runs up, but it is based on the assumption of static linking. How if ELF uses dynamic linking? Let’s identify the difference together through this article. What’s dynamic linking? Delaying the linking process to runtime, this is the core idea of dynamic linking. If program 1 and program 2 both need lib. When we run up program 1, lib will also be mapped into memory.
In this article, the loading process described is limited to ELF in Linux, not including how PE is loaded in Window. But don’t worry, many concepts (in addition to terminology) are similar in Window. Why not just map to the physical memory address? Why is program always loaded into virtual memory address? We already know that program would run up as a process, and each process tends to take all the memory alone by themselves.