Hi,

Currently, remote.c stores thread ids in the ptid.pid field, which
isn't good for multi-process support.  We need to be able to store
the {pid,tid} tuple in ptids to uniquely identify threads, when we
go multi-process.

So, I've made this patch to switch it into using ptid.tid, so
we get the ptid.pid field for storing real pids.

There are several hacks that we have to preserve due to the way
the protocol worked before vCont was around, and due to sometimes
GDB not knowing about the remote threads.  One of those is the
MAGIC_NULL_PTID "mechanism" which is used to have something
non-null in inferior_ptid when connected with stubs that
don't support any of the optional remote protocol extensions
related to thread support (T AA thread:TID, qC, qfThreadInfo, etc.).

I've tested this extensivelly by talking to a native gdbserver,
and native gdbserver with vCont disabled, and then also with a
gdbserver with vCont and all thread related packets and fields
disabled, to simulate old stubs and stubs that don't support
threads at all.

I didn't see any regression, and diffing the remote protocol
debug output logs in the cripled gdbserver cases showed no
differences (apart from thread ids, of course).

Does it look OK?

A good thing is that magic_null_ptid actually becomes safe and
unambigous, because a ptid_equal with a ptid of a real
thread id will always return false.  I'm relying on that
property on the next patch.

-- 
Pedro Alves