[lldb-dev] LLDB and QEMU

[Steve Pucci]

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

 - Steve


On Fri, Feb 14, 2014 at 9:13 AM, Steve Pucci <spucci at google.com> wrote:

> 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/20140218/9759700b/attachment.html>