[RFC] MERGEPID macro wrong ?
Pierre Muller
muller@cerbere.u-strasbg.fr
Wed May 30 00:50:00 GMT 2001
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
More information about the Gdb-patches
mailing list