Re: [RFC] MERGEPID macro wrong ?

[Pierre Muller <muller@cerbere.u-strasbg.fr>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]

At 20:49 29/05/01 , Kevin Buettner a écrit:
>On May 28,  1:31pm, Pierre Muller wrote:
>
> > The definition of MERGEPID macro currently on CVS seems
> > wrong to me:
> >
> > the macro is the following,
> >
> >    #define MERGEPID(PID,TID) ptid_build(PID,TID, 0)
>
>I think the comment in defs.h sort of explains this...
>
>/* Provide default definitions of PIDGET, TIDGET, and MERGEPID.
>    The name ``TIDGET'' is a historical accident.  Many uses of TIDGET
>    in the code actually refer to a lightweight process id, i.e,
>    something that can be considered a process id in its own right for
>    certain purposes.  */
>
>I.e, for MERGEPID, the TID parameter is actually a lightweight process
>id in most cases.
>
> > but ptid_build is defined as
> >
> > ptid_t
> > ptid_build (int pid, long lwp, long tid)
> >
> > So I think that the right macro should be
> >
> > #define MERGEPID(PID,TID) ptid_build(PID, 0, TID)
>
>If this is done, then the TIDGET macro would also have to change.  Some
>of the low level thread code might also have to change.  For the short
>term, I think it would be better to change the MERGEPID define to read
>as follows:
>
>#define MERGEPID(PID,LWP) ptid_build(PID, LWP, 0)
>
>Now that we have ptid_t with separate pid, tid, and lwp components we
>should able to clean up a lot of code which used to overload PIDs, LWPs
>and TIDs onto an int.

I think that would be indeed nicer,
because when you do a grep MERGEPID * in gdb dir you get the following:

defs.h:/* Provide default definitions of PIDGET, TIDGET, and MERGEPID.
defs.h:#define MERGEPID(PID, TID) ptid_build (PID, TID, 0)
gnu-nat.c:           proc->inf->pid, pid_to_thread_id (MERGEPID (proc->tid, 
0)));
lynx-nat.c:       inferior_ptid = MERGEPID (PIDGET (inferior_ptid), thread);
proc-service.c:#define BUILD_LWP(tid, pid)      MERGEPID (pid, tid)
procfs.c:  return MERGEPID (pi->pid, proc_get_current_thread (pi));
procfs.c:             retval = MERGEPID (pi->pid, proc_get_current_thread 
(pi));
procfs.c:                   temp_ptid = MERGEPID (pi->pid, temp_tid);
procfs.c:                   temp_ptid = MERGEPID (pi->pid, temp_tid);
procfs.c:  inferior_ptid = MERGEPID (pi->pid, proc_get_current_thread (pi));
procfs.c:  ptid_t gdb_threadid = MERGEPID (pi->pid, thread->tid);

As the distinction between tid and lwp is still rather obsucre to me,
I am just wondering if all the above uses of  MERGEPID
are completely aware of this subtility!
The BUILD_LWP macro seems to be a nice example showing that.

   Coming back to the ptid_t structure,
I still wonder how threads and processes are handled...

   Looking for instance in the win32-nat.c code, I see
that each thread is considered as a different process, why ??



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99