This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH RFC] process/thread/lwp id patch - phase 1
- To: Andrew Cagney <ac131313 at cygnus dot com>, Kevin Buettner <kevinb at cygnus dot com>
- Subject: Re: [PATCH RFC] process/thread/lwp id patch - phase 1
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Thu, 3 May 2001 16:28:49 -0700
- Cc: gdb-patches at sources dot redhat dot com
- References: <1010430174514.ZM31129@ocotillo.lan> <3AF1E24D.9080306@cygnus.com>
On May 3, 6:57pm, Andrew Cagney wrote:
> In terms of direction, I would expect tpid_t to eventually just be
> treated like a KEY that is used to locate the corresponding ``struct
> thread_info *'' object. It is a key because GDB retains it for longer
> than the lifetime of the corresponding thread_info object.
>
> With this in mind:
>
> > - This patch introduces some new macros, pid_to_ptid, null_ptid,
> > minus_one_ptid, and ptid_equal. These macros will be eliminated
> > in phase 3. In their place will be functions (for pid_to_ptid
> > and ptid_equal) and variables (for null_ptid and minus_one_ptid).
> > Other ptid accessors an a ptid constructor will be introduced at
> > the same time.
>
> is ptid_equal() needed? Won't memcmp() be sufficient?
The primary problem with using memcmp is that you need to supply it
with the address of a hunk of memory to be compared. Thus, while you
can do:
if (ptid_equal (ptid, pid_to_ptid (-1)))
...
I don't think the equivalent is possible with memcmp():
if (memcmp (&ptid, &(pid_to_ptid (-1)), sizeof (ptid_t)) == 0)
...
I.e, the compiler will complain about ``&(pid_to_ptid (-1))''.
A distinct equality operator for ptids also allows us to easily
redefine what it means for two ptids to be equal. E.g, in the
upcoming phase-3 patch, I'm going to propose that ptid_equal() be
defined as follows:
int
ptid_equal (ptid_t ptid1, ptid_t ptid2)
{
return (ptid1.pid == ptid2.pid && ptid1.lwp == ptid2.lwp
&& ptid1.tid == ptid2.tid);
}
Alternately, we'd get the same result by doing
return memcmp (&ptid1, &ptid2, sizeof (ptid_t)) == 0;
But, at some point we may find it desirable to consider two ptids
to be equal if the process id components are both 0 or both -1. E.g,
something like this...
int
ptid_equal (ptid_t ptid1, ptid_t ptid2)
{
if (ptid1.pid == 0 && ptid2.pid == 0)
return 1;
else if (ptid1.pid == -1 && ptid2.pid == -1)
return 1;
else
return (ptid1.pid == ptid2.pid && ptid1.lwp == ptid2.lwp
&& ptid1.tid == ptid2.tid);
}
Anyway, the point is that a distinct equality operator gives us a
lot more flexibility than hardwiring it to be memcmp everywhere.
Kevin