[lldb-dev] mach_vm_read_overwrite instead of mach_vm_read
Nick Blievers
nblievers at threatmetrix.com
Tue May 6 16:52:10 PDT 2014
Hi,
This isn’t something that is very important, but I was looking through the code and noticed that lldb uses mach_vm_read() and then a memcpy() (and mach_vm_deallocate()). It should, I think, be more efficient (and slightly simpler) to use mach_vm_read_overwrite() instead, the following should have the same net result with less code:
Index: tools/debugserver/source/MacOSX/MachVMMemory.cpp
===================================================================
--- tools/debugserver/source/MacOSX/MachVMMemory.cpp (revision 208138)
+++ tools/debugserver/source/MacOSX/MachVMMemory.cpp (working copy)
@@ -564,9 +564,9 @@
while (total_bytes_read < data_count)
{
mach_vm_size_t curr_size = MaxBytesLeftInPage(task, curr_addr, data_count - total_bytes_read);
- mach_msg_type_number_t curr_bytes_read = 0;
- vm_offset_t vm_memory = NULL;
- m_err = ::mach_vm_read (task, curr_addr, curr_size, &vm_memory, &curr_bytes_read);
+ mach_vm_size_t curr_bytes_read = 0;
+ vm_offset_t vm_memory = (vm_offset_t)curr_data;
+ m_err = ::mach_vm_read_overwrite (task, curr_addr, curr_size, vm_memory, &curr_bytes_read);
if (DNBLogCheckLogBit(LOG_MEMORY))
m_err.LogThreaded("::mach_vm_read ( task = 0x%4.4x, addr = 0x%8.8llx, size = %llu, data => %8.8p, dataCnt => %i )", task, (uint64_t)curr_addr, (uint64_t)curr_size, vm_memory, curr_bytes_read);
@@ -578,8 +578,6 @@
if (DNBLogCheckLogBit(LOG_MEMORY))
m_err.LogThreaded("::mach_vm_read ( task = 0x%4.4x, addr = 0x%8.8llx, size = %llu, data => %8.8p, dataCnt=>%i ) only read %u of %llu bytes", task, (uint64_t)curr_addr, (uint64_t)curr_size, vm_memory, curr_bytes_read, curr_bytes_read, (uint64_t)curr_size);
}
- ::memcpy (curr_data, (void *)vm_memory, curr_bytes_read);
- ::vm_deallocate (mach_task_self (), vm_memory, curr_bytes_read);
total_bytes_read += curr_bytes_read;
curr_addr += curr_bytes_read;
curr_data += curr_bytes_read;
I understand if this is somewhat low priority ;)
Oh the other hand, if it isn’t better, I’d be very curious why.
Cheers
Nick
More information about the lldb-dev
mailing list