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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > > On May 6, 2014, at 10:58 AM, Todd Fiala <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > -- > Todd Fiala | Software Engineer | [email protected] | 650-943-3180 > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
