mirror of
https://github.com/lifting-bits/remill
synced 2026-06-21 13:56:07 +00:00
Docs fix 404link and some typo! (#412)
* Update README.md fix missing link * Update LIFE_OF_AN_INSTRUCTION.md There are difference address between picture and example code. maybe it is just a little mistake * Update DESIGN.md between A and B from C... maybe it is wrong grammar. but English is not my first language. downstream tools can distinguish between LLVM `load` and `store` instructions from accesses to the modeled program's memory. => downstream tools can distinguish LLVM `load` and `store` instructions from accesses to the modeled program's memory. it seems more nature. (i think.)
This commit is contained in:
+1
-1
@@ -6,7 +6,7 @@ Remill translates machine code, and *only* machine code, into LLVM bitcode. The
|
||||
|
||||
Remill defers the "implementation" of memory accesses and certain types of control flows to the consumers of the produced bitcode. Deferral in this takes the form of Remill [intrinsics](https://github.com/lifting-bits/remill/blob/master/remill/Arch/Runtime/Intrinsics.h).
|
||||
|
||||
For example, the `__remill_read_memory_8` intrinsic function represents the action of reading 8 bits of memory. Via this and similar intrinsics, downstream tools can distinguish between LLVM `load` and `store` instructions from accesses to the modeled program's memory. Downstream tools can, of course, implement memory intrinsics using LLVM's own memory access instructions.
|
||||
For example, the `__remill_read_memory_8` intrinsic function represents the action of reading 8 bits of memory. Via this and similar intrinsics, downstream tools can distinguish LLVM `load` and `store` instructions from accesses to the modeled program's memory. Downstream tools can, of course, implement memory intrinsics using LLVM's own memory access instructions.
|
||||
|
||||
## Instruction semantics
|
||||
|
||||
|
||||
@@ -16,18 +16,18 @@ Below is a string representation of the data structures representing our example
|
||||
|
||||
```lisp
|
||||
;; mov eax, 1
|
||||
(X86 8048098 5 (BYTES b8 01 00 00 00)
|
||||
(X86 804b7a3 5 (BYTES b8 01 00 00 00)
|
||||
MOV_GPRv_IMMv_32
|
||||
(WRITE_OP (REG_32 EAX))
|
||||
(READ_OP (IMM_32 0x1)))
|
||||
|
||||
;; push ebx
|
||||
(X86 804809d 1 (BYTES 53)
|
||||
(X86 804b7a8 1 (BYTES 53)
|
||||
PUSH_GPRv_50_32
|
||||
(READ_OP (REG_32 EBX)))
|
||||
|
||||
;; mov ebx, dword ptr [esp + 8]
|
||||
(X86 804809e 4 (BYTES 8b 5c 24 08)
|
||||
(X86 804b7a9 4 (BYTES 8b 5c 24 08)
|
||||
MOV_GPRv_MEMv_32
|
||||
(WRITE_OP (REG_32 EBX))
|
||||
(READ_OP (DWORD_PTR (ADD (REG_32 SS_BASE)
|
||||
@@ -35,7 +35,7 @@ Below is a string representation of the data structures representing our example
|
||||
(SIGNED_IMM_32 0x8)))))
|
||||
|
||||
;; int 0x80
|
||||
(X86 80480a2 2 (BYTES cd 80)
|
||||
(X86 804b7ad 2 (BYTES cd 80)
|
||||
INT_IMMb
|
||||
(READ_OP (IMM_8 0x80)))
|
||||
```
|
||||
@@ -236,4 +236,4 @@ Remill has a lot of moving parts, and it takes a lot to go from machine code to
|
||||
|
||||
A key goal of Remill is to be explicit about control flows, memory ordering, and memory accesses. This isn't always obvious when looked at from the perspective of implementing instruction semantics. However, the bitcode doesn't lie.
|
||||
|
||||
The design of the intrinsics is such that a user of the bitcode isn't overly pigeonholed into a specific use case. Remill *has* been designed for certain use cases and not others, but in most cases, one can do as they please when it comes to implementing, removing, or changing the intrinsics. They are not defined for a reason!
|
||||
The design of the intrinsics is such that a user of the bitcode isn't overly pigeonholed into a specific use case. Remill *has* been designed for certain use cases and not others, but in most cases, one can do as they please when it comes to implementing, removing, or changing the intrinsics. They are not defined for a reason!
|
||||
|
||||
+1
-1
@@ -4,4 +4,4 @@ This document provides an index for topics relating to the design, implementatio
|
||||
|
||||
Remill is a [machine code](https://en.wikipedia.org/wiki/Machine_code#Machine_code_instructions) to [LLVM bitcode](http://llvm.org/docs/LangRef.html) [binary translation](https://en.wikipedia.org/wiki/Binary_translation) library. It provides APIs that enable other tools (e.g. [McSema](https://github.com/lifting-bits/mcsema)) to lift the instructions of binary programs into equivalent LLVM bitcode. Remill can and has been used by both static and dynamic binary translators.
|
||||
|
||||
Remill's approach to instruction lifting is showcased in the "[How instructions are lifted](docs/LIFE_OF_AN_INSTRUCTION.md)" document. It shows how machine code bytes are decoded and mapped to C++ functions that implement the operational semantics of instructions. The "[How to add and test an instruction](ADD_AN_INSTRUCTION.md)" document describes the formatting and structure of these C++ functions.
|
||||
Remill's approach to instruction lifting is showcased in the "[How instructions are lifted](LIFE_OF_AN_INSTRUCTION.md)" document. It shows how machine code bytes are decoded and mapped to C++ functions that implement the operational semantics of instructions. The "[How to add and test an instruction](ADD_AN_INSTRUCTION.md)" document describes the formatting and structure of these C++ functions.
|
||||
|
||||
Reference in New Issue
Block a user