This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] ptid_get_pid function vs. PIDGET macro
- To: Mark Kettenis <kettenis at wins dot uva dot nl>, gdb at sources dot redhat dot com
- Subject: Re: [RFC] ptid_get_pid function vs. PIDGET macro
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Mon, 8 Oct 2001 15:54:05 -0700
- References: <200110061257.f96CvtZ00321@delius.kettenis.local>
On Oct 6, 2:57pm, Mark Kettenis wrote:
> Ever since Kevin introduced `struct ptid' we have, in addition to the
> PIDGET, TIDGET and MERGEPID macros, a new set of functions ptid_build,
> pid_to_ptid, ptid_get_pid, etc. AFAIK, we've never talked about a
> policy how we're going to deal with them. IMHO we should try to
> eliminate the redundancy, and deprecate the macros. Do we agree on
> that?
Although not technically necessary, I'd like to see the unixware
threads port be made to use the same mechanisms as the other GDB
threads ports prior to eliminating PIDGET, TIDGET, and MERGEPID from
the GDB sources. (It's a happy accident that the PIDGET, TIDGET, and
MERGEPID defines in config/i386/tm-i386v42mp.h actually match those
found in defs.h.)
Anyway, the reason I'd prefer to do things in this order is that
ptid_get_lwp() is used for fetching both LWP ids and thread ids
on Unixware. If we get carried away and replace all of the macros
with their functional equivalents, it may be a lot harder to sort
things out for the SCO port at some point in the future.
Kevin