[lldb-dev] LLDB and QEMU

[Steve Pucci]

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...

Thanks,
  Steve


On Fri, Feb 14, 2014 at 8:42 AM, Todd Fiala <tfiala at google.com> wrote:

> Hey Abid,
>
> 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.
>
>
> On Fri, Feb 14, 2014 at 2:38 AM, Abid, Hafiz <Hafiz_Abid at mentor.com>wrote:
>
>> Hi All,
>> 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.
>> https://sourceware.org/gdb/onlinedocs/gdb/Stop-Reply-Packets.html
>> 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.
>>
>> Thanks,
>> Abid
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>
>
>
> --
> Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140214/29a44298/attachment.html>