`afbr`'s description isn't worded properly. It doesn't actually print addresses of `ret` instructions, but of instructions which cause the flow of the program to leave the function body, like `call`, `jmp`, `hlt` etc.
Linux 2.5.46 made changes to the ptrace(2) API to inform a tracer when various
events occur. These are known as PTRACE_EVENTs. Start handling PTRACE_EVENTs
by:
* Handling PTRACE_EVENT_FORK and PTRACE_EVENT_EXIT
* For _FORK, stores the newly created pid in dbg->forked_pid
* Add the "dpc" command to select the most recently forked child process.
* Add the "dpc*" command to show the recently forked process' pid.
Additional minor changes to white space are included.
NOTE: This partially addresses #3549. It does handleLinux before 2.5.46.
* Fixes#4875: Refactor process listing
* Move procfs-based process listing into linux_debug.c, guarded by __linux__
* Provide a warning and eprintf a TODO on the remaining platforms.
* Break reusable parts into linux_get_proc_pid and call it as needed.
* Add/remove comments for clarity
* Address feedback and re-enable non-Linux
CDIV deoptimization
===================
This patch implements hints in the disassembler that
aim to assist the user in reading compiler-optimized divisions
by analysing the involved magic number.
Background
==========
Since integer divisions are usually very expensive on most architectures,
compilers try very hard to substitute them with cheaper operations.
One of the more advanced substitutions is described in the book __Hacker's Delight__,
chapter 10.
An actual implementation of the described algorithm in LLVM can be found in the
functions: `TargetLowering::BuildSDIV()` and `APInt::magic()`.
The optimization approximately transforms e.g.
```asm
xor edx, edx
idiv 39
```
into
```asm
mov eax, edi
mov edx, 0xd20d20d3
imul edx
lea eax, [rdx + rdi]
sar edi, 0x1f
sar eax, 5
sub eax, edi
```
Reading the optimized version and __seeing__ the constant 39 seems difficult.
Therefore I try to provide a small hint to the user.
Limitations
===========
* The current implementation only takes the magic number into account,
therefore it may result in false positives.
* Due to the nature of the optimization, the given hint may be off by a power of two.
Fixing this would require to analyse the following shift instructions.
* The hint is only shown in the line containing the magic number.
The user still has to know which of the following instructions belong to the optimization.
TODO
====
* Implement the corresponding analysis for unsigned integers
* Implement the corresponding analysis for 64-bit integers.
* Improve the heuristic by also looking at the next few instructions.
( I don't really know how to iterate over the instructions in the disassember
in a non-deprecated way. Maybe someone can drop me a hint? )
* Implement an exact analysis using the actual dataflow in radeco and use it
to revert the optimization. ( I suppose this is outside the scope of radare )
* Fix "dbm" help string
* Save <module>+<offset> as the name when using dbm
* Fix allocation patterns for "module"
* Remove commented out code
* White space fixes
