bypass -data-read-memory-bytes when using lldb

[swermin]

On LLDB backed debugging, the disassembly view does not work at all. It just shows ?? on all instructions.

Turns out the call -data-read-memory-bytes does not work with lldb, and it returns error, namely LLDB unable to read entire memory block of n bytes at address 0x0....

This PR adds a check to see if lldb is the debugger used, and if lldb is being used then do not call the _process.FindValidMemoryRange function. Instead use the parameters sent in to the function and calculate the start and end addresses.

This is how the assembly window looks like with this patch:

[gregg-miskelly]

Thanks for working on fixing this! Do you know if lldb-mi's implementation of -data-read-memory-bytes is entirely busted? Or just doesn't correctly support -o <offset-value>? I ask because there are two other callers of FindValidMemoryRange, so I would think we would want to fix FindValidMemoryRange to do something different from LLDB rather than avoiding calling it in just the one code path, unless it just doesn't handle the offsets, as the other two code paths with use an offset of 0.

[swermin]

It seems like the read-memory is not working as we think it is with lldb.
I disassembled the -data-read-memory-bytes and replicated the functionality directly in lldb instead of using lldb-mi.

It is basically just calculating the address and then using it to fetch the memory.

So for this call, -data-read-memory-bytes -o -1664 0x0000000002518aa0 1690, it calculates the start address as 0x0000000002518420 and then tries to fetch the memory. LLDB in that case returns core file does not contain 0x2518420.

but if I use the same startAddress in -data-disassemble then I do get a correct response back.
For reference: -data-disassemble -s 0x0000000002518420 -e 0x0000000002518aba -- 2

I do wonder if there are differences in the addresses when it comes to disassembly vs addresses that are used for reading the memory?

[swermin]

Follow-up:
My main use case for using MIEngine is to debug core dumps with lldb. I did a bit more investigation and the issue I am trying to solve is limited to core dumps. The codebase works as normal if I run a linux executable and put a breakpoint anywhere in the code.
Booting up a core dump though is broken. So I wonder if the memory within the core dump doesn't match what the disassembly is trying to use?

I don't see how we could make the read-memory-bytes work in this specific scenario. Do you have any ideas or thoughts?

As an alternative on this I do wonder if we should limit this fi to core dumps + lldb only.

[gregg-miskelly]

What that code is attempting to do is implement disassembly through all addresses. This is a bit tricky because we don't know what range of addresses are actually valid. So, for example, the UI could be currently be starting with the 3rd instruction of a method, and the user pages up so we now have a request to disassembly through the first two valid addresses, but also a bunch of stuff that might be non-instructions and might not even be valid memory.

FindValidMemoryRange is attempting to deal with that by telling us the range of memory around address that is valid.

There are three possible ways we could probably deal with this:

1. If the LLDB implementation of -data-disassemble already fully handles the problem of both requesting instructions before valid memory and also after valid memory, I think you could just change FindValidMemoryRange to be a nop implementation that will just always return (start = address+offset, end = address+offset+count). This is your fix, except it covers all of the cases where FindValidMemoryRange is used. I think this will be enough to make things work, though
2. If the LLDB implementation of -data-disassemble doesn't fully handle the problem, and -data-read-memory-bytes returns partial reads as long as the start address is valid, then what you have is probably correct, but I would suggest a slight tweak of moving the implementation into FindValidMemoryRange and just have it bail out when offset < 0 and we are dealing with LLDB.
3. If the LLDB implementation of -data-disassemble doesn't fully handle the problem, and -data-read-memory-bytes really only returns bytes if all the bytes are readable, then we probably need a fix which will binary search using -data-read-memory-bytes to try and figure out which bytes are valid

[swermin]

So I've spent a lot of time trying to investigate what the ramifications are if we bypass the -data-read-memory-bytes for lldb.

So far I have not seen any issues by just using the -data-disassemble. Though I am worried about hidden problems down the line. To make the blast radius of this change small I made sure that in the function FindValidMemoryRange we only ever bail on using the -data-read-memory-bytes if we are debugging a coredump together with lldb. Everything else should be using the normal flow.

To make sure that this isn't breaking anything I had this fix locally for few days and it seems like things are working as intended.

How are you feeling about this? Having the code bail out in case of CoreDump + LLDB?

• My two cents here is that the normal debugging should stick to use the same code as usual, since that has been working fully for a long time. When debugging a coredump, the use cases on the FindValidMemoryRange is small enough to not be a problem if we bypass it.