chinggg

To reproduce in `example/explorer.js`, add `scrollable: true` to tree option, it will throw `RangeError: Maximum call stack size exceeded` immediately.

Thanks! It seems to be a different tracer compared with the existing trace extension made by @elicn

@elicn Yes, r2 also relies on capstone for disassembly. But it can provide results with **addresses resolved as flags** directly. For example, now we can only see disasm `call 0x004019`,...

In the latest commits, I integrate r2 extension into qiling core again, but as `cached_property`. To demonstrate the advantage of introducing r2, I modify the breakpoint part of qdb, now...

It seems I ignore the fact that r2 can only provide disasm for binary itself, but not the libraries, so it should fallback to the existing disassembler approach when disasm...

@wtdcode I have tried to use r2 on `msvcrt.dll`, it's extremely slow. I must wait for 10s+ for r2 to analyze a single library. Moreover, since the library does not...

@wtdcode @elicn Thanks for mentioning **multiple r2 instances** and **patched binaries**. I think we can solve it later but not here, since we really have to take many things into...

I agree that we really need well-design decisions when integrating r2 into qiling. As @wtdcode mentioned, syncing r2 memory with Qiling (Unicorn) memory is important for building our flag-address system,...

Atfer https://github.com/qilingframework/qiling/pull/1196/commits/bc516a9d8a330cb176e0f5c8e09901f4d1bdd062, r2 is sill **optional dependency** and **partially** integrated into qiling core only if `r2libr` is installed. Users can use qiling as usual if they don't install `r2libr`. Please...

Already detach r2 extension from qiling core, r2.disassembler now monkey patch `QlArchUtils.disassembler`