This was originally used to cause a seek to the next block prior to
reading such that successive calls to r_core_block_read() would progress
through memory one block at a time. This was broken, though, by commit
452669d941 ("more cleanup in r_core_block_read") when when it used
`next' to directly calculate the offset rather than via a seek.
Only one call site remains that attempts to read the next block instead
of the current, and this probably was not even observable due to the
"hacky fix" added in commit 3bfa61946e ("Cleaner pvj, fix tinype load,
and honor 'ao N's").
The current of semantics of `next' appear to be broken and there is very
little dependence on it. If the original behavior should be restored
anywhere, it would be much better to add a new function, or just do the
seek explicitly, rather than parameterizing r_core_block_read() on it.
Commit 57b199789d ("Reread block after undo seek. Fixes dbg.status
issue") reads the *next* block into the buffer rather than the current.
This breaks backwards seeking as can be seen in the following example:
$ r2 -N malloc://0x4000
[0x00000000]> b 64
[0x00000000]> wb 38
[0x00000000]> s 64
[0x00000040]> wb deadbeef
[0x00000040]> s-32
[0x00000020]> px
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x00000020 dead beef dead beef dead beef dead beef ................
0x00000030 dead beef dead beef dead beef dead beef ................
0x00000040 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00000050 0000 0000 0000 0000 0000 0000 0000 0000 ................
[0x00000020]> s+16
[0x00000030]> px
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x00000030 3838 3838 3838 3838 3838 3838 3838 3838 8888888888888888
0x00000040 dead beef dead beef dead beef dead beef ................
0x00000050 dead beef dead beef dead beef dead beef ................
0x00000060 dead beef dead beef dead beef dead beef ................
The first block to a string of ASCII '8' bytes and the second to
0xdeadbeef. We then seek backwards 32 bytes from our current 64 byte
offset but a dump at the resulting offset shows data from half way into
the second block (i.e., offset 0x60.) Dumping again after seeking 16
bytes forward shows the expected last bit of the first block. Clearly
the intent was to reread the current block, not the next block, after an
undo or backward seek.
NOTE: The above example will only work after applying the previous
commit as rereading the buffer when displaying the prompt hides this
bug.
Additionally, since the commit intended to reread the buffer only after
an undo seek, do not do this at all on a backward seek.
Commit 3bfa61946e ("Cleaner pvj, fix tinype load, and honor 'ao N's
help") added a hack to reread the current block when printing the
prompt. This has the drawback of causing scripts loaded via the `-i'
command line option to potentially behave differently than reading the
commands via stdin. Remove the hack and fix the bugs.
* /R can now classify nop gadgets
* MovRegs and LoadConst pattern classification for /R
* Moved classification logic in separate file
* Adding Arithmetic Pattern classification for /R (work in progress)
Enabling stepping over
Basic (sym.imp.*) call catching routines
Fixing esil tracing bug and verbosity
Adding some apis for handling function prototypes and abstacting sbd queries
Fixing the double execusion bug in esil tracing
passing types into vars for `stack`
fixing trailing spaces
doing the regester branch
doing the stack_rev
Now we build a list of ranges (RAnalRange) based on anal hints to handle the
bits in a better way in the case of arm/thumb
Now instead of asm.bits that rules the whole binary we can define ranges with
anal hints
* First approach to afCl/cdecl. Thanks @oddcoder.
* Remove compilers that do not exist for AVR
* Remove unnecessary platform-specific code since 'cc-arch-bits' should be already a stable convention.
* Typo on the afC way
correct the add section check
keep commented part to it's original code
int to ut64
minor fix and limit buffer size in case file size cannot be allocted
remove section check
show size in readable format
minor changes
renaming afa, afv and afe to afvb afvr, and afvs respectively
making arguments analysis obeys e anal.vars
improving the json format for args/vars
fixing varsub to use the new comands for x86 and arm
fixing var commenting commands to use the new commands var configuration
The major contribution here is completely re-worked breakpoint hit/recoil
handling. This work fixes#4907 and lays the ground work for future native
debugger improvements (multi-threading, etc).
* Give a human friendly type to enums
* Change many wait functions to return RDebugReasonType
* Better return checking (from r_debug_reg_sync, r_bp_restore)
* Optimized register synchronization
* Lots of comments and whitespace changes
* Improved inferior death detection
Handle EXIT_PID events differently than DEAD process events
* Move breakpoint/recoil handling to wait/cont/step
Rather than handing breakpoint related things inside cmd_debug.c, do that
inside the r_debug API functions. This seems like the most logical place for it
to live since it should apply to just about any platform/architecture. This
also centralizes calling into "cmd.bp" handling via the CoreBind callback.
* Track how the caller wishes to continue
It turns out that handling break point recoils is very complicated. The ptrace
API on Linux returns SIGTRAP for just about every type of operation (not just
breakpoints getting hit). Add the "recoil_mode" flag to indicate whether we are
single-stepping or continuing and whether or not we are inside the recoil.
* Proper handling for swstep=true
Since r_debug_step_soft calls r_debug_continue, it's already hitting the recoil
case there. Move the recoil handling from r_debug_step to r_debug_step_hard
only.
For the swstep=true case, special handling is required inside r_debug_recoil.
By resetting all of the breakpoints except the one we just hit, we ensure we
can step the original instruction and hit the new swstep breakpoint. Add a new
bp function called r_bp_restore_except to do this.
To make matters worse, we cannot use a BreakpointItem pointer because that
leads to a use-after-free condition. Instead, we the breakpoint address
instead.
Now breakpoints should work regardless of the swtep setting.
* Always call the recoil before continuing
Some callers of r_debug_continue might not have ever inserted any breakpoints
before. If we don't restore breakpoints before each call to the underlying
continue we won't hit them.
* Hide software step breakpoint events from the user
When a breakpoint even happens due to a software-step, hide it from the user.
They aren't really breakpoints as far as they are concerned.
* Improve process exit handling on Linux
There are three types of process exiting events on Linux:
1. PTRACE_EVENT_EXIT occurs just before a process exits. It's not possible to
prevent it from exiting, but it can be used to inspect the pre-exit state.
2. The process can exit for a variety of reasons and we can notice when we call
waitpid(2).
3. The process could die randomly on us :-/
On Windows, h->wait will return R_DEBUG_REASON_EXIT_PID, but it's more likely
on Linux to find out the process is already dead.
* Check more bits within waitpid status
We can often make a decision about what happened strictly by looking at the
status returned from waitpid. In other cases, we need to call
r_debug_handle_signals.
If we reach the end of this function without knowing what happened, consider it
an error.
Distinguish between "dXX" and "dXXYY" or "dXX?". Treat the latter two the same.
This provides the least surprise to the user when they mistype something.
Improve default handling in arp/drp
* Adds a new command "drp." for showing the register profile size.
* Provides better help for drpXXX commands.
* Provides help in the default case (eg. drpz)
* Fixes indentation
* Provides correct help strings for arp vs. drp
Improve default handling for "dko"
* Rework "dko" handling to simplify
* Use r_core_cmd_help
* Show help when things like "dkox" are used
* Prevent allocation/free when not necessary
removing argument detection extension used in af now args are seperately detected by afCa
aa = af + afCa
using aliases as well as real registers
rewritten varsub
Fixing some of Arm esil and optimizing them for arg/var detection
`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.
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
* refactor function listing code
* adhere to style guide
* use tabs instead of spaces
* recover default behaviour for afi commands
* work in commentary and fix the two regression tests I broke
* some more cosmetic changes
* shorten function names
