[lldb-dev] debugserver inferior launch, stopped, $qC and $? thread not matching
Todd Fiala
todd.fiala at gmail.com
Wed May 7 09:01:03 PDT 2014
Thanks for sharing, Jean-Daniel.
That definitely sounds better than what I'm doing. I also wasn't passing
the --framework option to the test runner. That might be why I'm getting
these failures at top of tree. I'm getting these failures as of about 30
minutes ago, clean top of tree build with no local changes: (r208204).
Failing Tests (9)
FAIL: LLDB (suite) :: TestMultithreaded.py (Darwin
tfiala-macbookpro.roam.corp.google.com 13.1.0 Darwin Kernel Version 13.1.0:
Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
i386)
FAIL: LLDB (suite) :: TestDataFormatterObjC.py (Darwin
tfiala-macbookpro.roam.corp.google.com 13.1.0 Darwin Kernel Version 13.1.0:
Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
i386)
FAIL: LLDB (suite) :: TestDataFormatterStdMap.py (Darwin
tfiala-macbookpro.roam.corp.google.com 13.1.0 Darwin Kernel Version 13.1.0:
Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
i386)
FAIL: LLDB (suite) :: TestDataFormatterStdVector.py (Darwin
tfiala-macbookpro.roam.corp.google.com 13.1.0 Darwin Kernel Version 13.1.0:
Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
i386)
FAIL: LLDB (suite) :: TestProcessLaunch.py (Darwin
tfiala-macbookpro.roam.corp.google.com 13.1.0 Darwin Kernel Version 13.1.0:
Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
i386)
FAIL: LLDB (suite) :: TestStopHookMechanism.py (Darwin
tfiala-macbookpro.roam.corp.google.com 13.1.0 Darwin Kernel Version 13.1.0:
Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
i386)
FAIL: LLDB (suite) :: TestRegisterVariables.py (Darwin
tfiala-macbookpro.roam.corp.google.com 13.1.0 Darwin Kernel Version 13.1.0:
Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
i386)
FAIL: LLDB (suite) :: TestObjCMethods.py (Darwin
tfiala-macbookpro.roam.corp.google.com 13.1.0 Darwin Kernel Version 13.1.0:
Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
i386)
FAIL: LLDB (suite) :: TestTargetAPI.py (Darwin
tfiala-macbookpro.roam.corp.google.com 13.1.0 Darwin Kernel Version 13.1.0:
Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
i386)
On Wed, May 7, 2014 at 8:29 AM, Jean-Daniel Dupas <mailing at xenonium.com>wrote:
> I don't like having all project output lying in my profile Library, so I
> changed Xcode preferences to generate build product in the project
> directory instead (in Xcode Preferences > Location, Derived Data: Relative).
>
> Then, I have a simple dotest.sh script in tests that launch dotest.py
> passing the right path for executable and I launch the tests manually.
>
> ---- dotest.sh
> #!/bin/bash
>
> # We need an absolute path.
> pushd `dirname $0` > /dev/null
> SELF=`pwd`
> popd > /dev/null
>
> LLDB_DIR=`dirname $SELF`
> PRODUCT_DIR="$LLDB_DIR/DerivedData/lldb/Build/Products/Debug"
>
> # export LLDB_LOG=lldb.log
> export PYTHONPATH="$PRODUCT_DIR/LLDB.framework/Versions/A/Resources/Python"
>
>
> COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>
> ./dotest.py --executable "$PRODUCT_DIR/lldb" --framework
> "$PRODUCT_DIR/LLDB.framework" -A x86_64 -C $COMPILER $*
> ---------------------
>
>
> Le 7 mai 2014 à 16:57, Todd Fiala <tfiala at google.com> a écrit :
>
> Hey Greg,
>
> I have this implemented locally, just working through an issue where lldb
> gets hung when attached to debugserver, waiting for the inferior's initial
> state change to become stopped.
>
> I'm seeing a few test failures as well, going back to top of tree to see
> if I'm introducing them.
>
> What's the best practice for using the output directory settings in Xcode?
> Right now I'm using the
> ~/Library/Developer/Xcode/DerivedData/{some-generated-name-here} directory.
> I'm then using a soft link to that directory as the '--executable=' part
> of the test runner. What do you guys do for build output, and how do you
> run tests?
>
> Thanks!
>
> -Todd
>
>
> On Tue, May 6, 2014 at 11:42 AM, Todd Fiala <todd.fiala at gmail.com> wrote:
>
>> Ok. I'll get that patched up and make sure all the tests passing before
>> are still passing afterwards.
>>
>>
>> On Tue, May 6, 2014 at 11:33 AM, Greg Clayton <gclayton at apple.com> wrote:
>>
>>>
>>> On May 6, 2014, at 10:58 AM, Todd Fiala <todd.fiala at gmail.com> wrote:
>>>
>>> > It appears gdbserver really returns the thread id as documented.
>>> >
>>> > Greg - I can get a patch together so we follow the documented protocol
>>> in lldb. Before I look at that, is there any side effect you'd be
>>> concerned about with moving the $QC response to report the current
>>> thread-id?
>>>
>>> LLDB currently assumes that qC responds with the PID of the process. Any
>>> change we do will require a change over to using the qProcessInfo packet,
>>> and if the qProcessInfo doesn't work it should fall back onto the old qC
>>> packet behavior. All old debugserver binaries that are built into old iOS
>>> developer disk images still need to work, so we have to make sure we don't
>>> ruin that.
>>>
>>> So to fix this we should modify:
>>>
>>> GDBRemoteCommunicationClient::GetCurrentProcessID()
>>>
>>> to call GDBRemoteCommunicationClient::GetCurrentProcessInfo() and see if
>>> we have process info. If we do, we will need to modify:
>>>
>>> GDBRemoteCommunicationClient::GetCurrentProcessInfo()
>>>
>>> to cache all of the returned (I don't see it caching the returned pid).
>>> Then we return the process ID if all goes well. Else we should fall back to
>>> returning the result of the "qC" packet for only for "arm*-apple-ios"
>>> targets just to make sure we don't break iOS.
>>>
>>>
>>> >
>>> > Thanks,
>>> > Todd
>>> >
>>> >
>>> > On Tue, May 6, 2014 at 8:27 AM, Todd Fiala <todd.fiala at gmail.com>
>>> wrote:
>>> > I see the issue.
>>> >
>>> > In debugserver and lldb-platform's impl (which llgs uses), qC is
>>> returning the process id. I *think* this is wrong according to the gdb
>>> remote protocol, per the protocol documentation here:
>>> >
>>> > ‘qC’
>>> > Return the current thread ID.
>>> > Reply:
>>> >
>>> > ‘QC thread-id’
>>> > Where thread-id is a thread ID as documented in thread-id syntax.
>>> > ‘(anything else)’
>>> > Any other reply implies the old thread ID.
>>> >
>>> > This raises a general question. If we have the protocol documented
>>> and we're not following it exactly (and provided the documentation isn't
>>> just plain wrong even for gdb), do we want to fix up lldb to match the
>>> protocol? Or do we keep things the same, and document that we're deviating
>>> form the protocol as written? I'd prefer to match the protocol for
>>> spec-following and iteroperability reasons.
>>> >
>>> > In the case of Linux, this issue wouldn't be discovered in the case of
>>> launching a process since the process id happens to also be the thread id
>>> of the first thread - hence this case the actual use of the pid instead of
>>> the tid in the $QC response packet wasn't detected.
>>> >
>>> > Let me know what you think and I'll fix it up (including the RNBRemote
>>> side). I may swing over to gdb/gdbremote from MacOSX homebrew/MacPorts to
>>> see if gdb really uses the thread id or the process id - that will at least
>>> rule out if the docs are correct.
>>> >
>>> > -Todd
>>> >
>>> >
>>> > On Mon, May 5, 2014 at 10:45 PM, Todd Fiala <todd.fiala at gmail.com>
>>> wrote:
>>> > Hi Greg,
>>> >
>>> > I'm about to add a protocol-level test for llgs and debugserver that
>>> verifies that a launched inferior process's initial reported thread (i.e.
>>> response to $qC) is the same thread that reports when asking for stop state
>>> ($?), or at least that the thread-id is present in the threads listed when
>>> QListThreadsInStopReply is available. What I'm finding on debugserver on
>>> MacOSX is that right after the successful launch with $A, the $qC query
>>> responds with a $QC{thread-id}. The very next $?, though, without any
>>> intervening resume operation, lists the threads but doesn't contain the
>>> {thread-id} from the $QC.
>>> >
>>> > Here's a real transcript (with non-interesting bits removed). It's
>>> from a debugserver started with no inferior, then attached to by lldb, then
>>> launching the first inferior process.
>>> >
>>> > ...
>>> > <lldb.driver.main-thread> < 27> send packet:
>>> $QListThreadsInStopReply#21
>>> > <lldb.driver.main-thread> < 6> read packet: $OK#00
>>> > <lldb.driver.main-thread> < 13> send packet: $qHostInfo#9b
>>> > <lldb.driver.main-thread> < 122> read packet:
>>> $cputype:16777223;cpusubtype:3;ostype:macosx;watchpoint_exceptions_received:after;vendor:apple;endian:little;ptrsize:8;#00
>>> > ...
>>> > <lldb.driver.main-thread> < 66> send packet:
>>> $A56,0,2f55736572732f746669616c612f706c61792f6370702f68656c6c6f#a0
>>> > <lldb.driver.main-thread> < 6> read packet: $OK#00
>>> > <lldb.driver.main-thread> < 18> send packet: $qLaunchSuccess#a5
>>> > <lldb.driver.main-thread> < 6> read packet: $OK#00
>>> > <lldb.driver.main-thread> < 6> send packet: $qC#b4
>>> > <lldb.driver.main-thread> < 9> read packet: $QC980#00 <<< Doesn't
>>> this say the app is launched, stopped, and thread-id 980 is selected?
>>> > <lldb.driver.main-thread> < 5> send packet: $?#3f
>>> > <lldb.driver.main-thread> < 503> read packet:
>>> $T11thread:63f5;qaddr:a0;threads:63f5;00:0000000000000000;01:0000000000000000;02:0000000000000000;03:0000000000000000;04:0000000000000000;05:0000000000000000;06:0000000000000000;07:68f8bf5fff7f0000;08:0000000000000000;09:0000000000000000;0a:0000000000000000;0b:0000000000000000;0c:0000000000000000;0d:0000000000000000;0e:0000000000000000;0f:0000000000000000;10:2810c05fff7f0000;11:0002000000000000;12:2b00000000000000;13:0000000000000000;14:0000000000000000;metype:5;mecount:2;medata:10003;medata:11;#00
>>> > ...
>>> >
>>> > The $? response seems to say it only has one thread, 63f5. I would
>>> expect at least the 980 thread-id reported in the initial qC packet to
>>> exist somewhere.
>>> >
>>> > What am I missing?
>>> >
>>> > Thanks!
>>> >
>>> > --
>>> > -Todd
>>> >
>>> >
>>> >
>>> > --
>>> > -Todd
>>> >
>>> >
>>> >
>>> > --
>>> > -Todd
>>>
>>>
>>
>>
>> --
>> -Todd
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
--
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140507/9c3e676c/attachment.html>
More information about the lldb-dev
mailing list