I was trying to make the LLDB talk to QEMU. I have identified a few problems as described below. I will be sending patches in the coming days. Just wanted to inform the community in case someone else is also working in this area.
1. The thread ids sent by the qemu start with 0. In LLDB, we treat 0 as invalid thread id. Probably we need to change the definition of LLDB_INVALID_THREAD_ID.
2. The stop reply packet from qemu is 'S05'. Code in ProcessGDBRemote::SetThreadStopInfo () does not handle this case properly. It assumes that there will be n:r pair with thread info.
3. We obviously need to provide a target description file with correct register information for qemu.
4. The Posix dynamic loader is trying to use auxv vector on host for calculating the entry address for remote target (AuxVector::GetAuxvData). This can only works when the inferior and debugger are on the same system. Due to this reason, we end up calculating wrong load address for remote case. We may like to add support for 'qXfer:auxv:read' but should also deal better when this information is not supplied by the remote target.
Thoughts/comments are most welcome.
Steve Pucci, working on getting lldb working with a stock Android gdbserver, has run into at last one of those issues above (I think issue 4). He’ll probably have some comments on at least a part of it.
Right. I’ve actually got a sandbox where I’m trying to load the auxv via the packet right now – it’s almost coded but I’m working on something else until at least Monday.
It’s not clear to me what the right architecture here is. Up until this week I was proceeding under the assumption that in the remote case (where we’re using ProcessGDBRemote) we should have a dynamic loader that is specific to that case, and in another sandbox I have a DynamicLoaderPOSIXDYLD plug-in that loads library load addresses via the qXfer:libraries:read and qXfer:libraries-svr4:read packets (that code is working, but the rest of the plug in isn’t written yet). But as I get more into the implementation I’m wondering if maybe we should just make sure that the POSIX dynamic loader does all of its actions via abstract methods that will go across the gdbserver as required to load memory from the target.
Greg actually suggested the latter approach quite a while back, but I didn’t realize at the time how much of lldb abstracts the way we access target information, so when I ran into the issue with auxv I thought it was the tip of a larger iceberg and I went down the path of creating a special dynamic loader plug-in.
I’ll know more next week after I try loading the auxv via packets. In the meantime if anyone has any thoughts, please feel free to comment…
(by “Monday” I seem to have meant “virtual Monday after the holiday”).
I have some code in my sandbox that properly reads the auxv via the packet, and it certainly looks like it’s working (auxv entries that are addresses look like addresses, and auxv entries that look like numbers look like reasonable numbers), but I can’t fully test it because I have another issue specific to debugging on Android.
The way I’ve changed it to work is that AuxVector::GetAuxvData(), instead of delegating to the Host, delegates to the process. The base Process delegates to the Host as before, but ProcessGDBRemote asks via the packet (if it’s supported, otherwise falling back to the base Process implementation).
If anyone is interested in this right away I can break it out as a separate patch; otherwise I’ll wait until I can get it fully tested on my system.