labath added a comment. In D53753#1504645 <https://reviews.llvm.org/D53753#1504645>, @aleksandr.urakov wrote:
> In D53753#1504589 <https://reviews.llvm.org/D53753#1504589>, @labath wrote: > > > When we evaluate an expression, we jit a bunch of opcodes into the inferior > > memory and then have it execute them. For that to work, we need to allocate > > some memory in order to store the opcodes. We cannot use the general > > expression engine to jit that expression, as we would be back to square > > one, so we manually set the PC to the entry point of the mmap function, and > > set the argument values as if it was being called. Then we just let the > > inferior loose and have it allocate the memory for us and return it. For > > this to work, we need abi knowledge both to correctly set the arguments of > > mmap, and to retrieve its result. > > > Got it, thanks! There's a different approach on Windows: for now we just call > `VirtualAllocEx`, which can allocate memory in another process. But it will > not work for the remote debugging case. Sure it will. You just need to call that function from lldb-server in response to the `_M` packet. The `_M` packet is our primary method of allocating memory, and the `mmap` thingy is a fallback for platforms where allocating memory is not that easy. (Actually, there is a relatively easy way to allocate memory from lldb-server on linux too, which is to (set up appropriate registers and then) have the inferior execute the `int 0x80` instruction. That would bypass the mmap function and jump straight to the kernel syscall. It would have the advantage of working in situations where the mmap libc function may not be available, but it's a bit of pain to set up so, i haven't tried yet to implement that.) Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D53753/new/ https://reviews.llvm.org/D53753 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
