From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Mark Kettenis , gdb@sources.redhat.com Subject: Re: [RFC] ptid_get_pid function vs. PIDGET macro Date: Mon, 08 Oct 2001 15:54:00 -0000 Message-id: <1011008225405.ZM9197@ocotillo.lan> References: <200110061257.f96CvtZ00321@delius.kettenis.local> X-SW-Source: 2001-10/msg00086.html 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