LLDB was using packet size advertised by the target as the max memory size to write in one go. It is wrong because packets have other overhead apart from memory payload. Also memory transferred through 'm' and 'M' packets needs 2 bytes in packet to transfer 1 of memory.
Details
Diff Detail
Event Timeline
We need to check stub_max_size to make sure we don't get an integer underflow.
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp | ||
---|---|---|
3999 | You need to check "sub_max_size" here. What if it says 64? We will then use a very large unsigned number UINT64_MAX - 6. |
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp | ||
---|---|---|
3999 | Thanks for review. I had a check in my development branch then removed it as the scenario seemed unlikely and there was not a good way to return error from this function. I was inclined to put this check in DoMemoryWrite/read and check the exact size every time but it looks overkill. The check added in this revision probably should be enough. |
A few cleanups on the logging. See inlined comments.
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp | ||
---|---|---|
4004 | We should use a GDB remote log channel instead of the LLDB channel. Since this is communication based I suggest: Log *log(ProcessGDBRemoteLog::GetLogIfAnyCategoryIsSet(GDBR_LOG_COMM| GDBR_LOG_MEMORY)); | |
4006–4007 | Missing space between "small." and "LLDB". We should also warn once, not every time. |
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp | ||
---|---|---|
4006–4007 | This function has a check at the top so the packet size is checked only once. |
See easy inline fix and this will be good to go
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp | ||
---|---|---|
4004 | LogIfAny, not LogIfAll. Then either bit will work to show this. |
You need to check "sub_max_size" here. What if it says 64? We will then use a very large unsigned number UINT64_MAX - 6.