> 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 tracked down my issue. I just put up a [PATCH] for this. On Wed, May 7, 2014 at 7:57 AM, Todd Fiala <[email protected]> wrote: > 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 > > -- -Todd
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
