Le 2 déc. 2011 à 01:47, Greg Clayton a écrit : > > On Dec 1, 2011, at 2:55 PM, Jean-Daniel Dupas wrote: > >> >> Le 1 déc. 2011 à 19:52, Greg Clayton a écrit : >> >>> It was this way after misinterpreting what the GPLv2 version of GDB does >>> (our darwin version) with the response. So it has been wrong for a while >>> and does need to be fixed. > > Part of the reason we did this too was the GDB remote specification docs: > > > current thread qC Return the current thread id. > reply QCpid Where pid is a HEX encoded 16 bit process id. > reply * Any other reply implies the old pid. > > It says "process id" is returned, not thread id…
OK. Look like it has been corrected though. >>> We need to add a new packet that gets information about the process >>> (something like "qProcessInfo") that is being debugging in the case where >>> we attach by name and need to know the process ID of what we attached to. >> >> Isn't what qGetPid already does ? > > Not sure. Is there a home for the one true GDB remote specification? I don't > see this packet in this: > > http://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets > http://sources.redhat.com/gdb/current/onlinedocs/gdb.html#General-Query-Packets > > Where are you seeing this packet? We don't look at any GPLv3 GDB sources at > Apple, so we can't look there. My bad. You're right, it's not in any specification. I just found it declared and supported in debugserver, but didn't checked if it was a lldb defined packet or a gdb one. > Also, we want more than just the PID, we want architecture, pointer size, and > vendor, OS, and other key value pairs, and thus we will soon implement the > qProcessInfo packet. Make sense. -- Jean-Daniel _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
