This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH RFC] process/thread/lwp id patch - phase 1


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]