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
