From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Kevin Buettner Cc: Mark Kettenis , gdb@sources.redhat.com Subject: Re: [RFC] ptid_get_pid function vs. PIDGET macro Date: Tue, 09 Oct 2001 22:28:00 -0000 Message-id: <3BC3DC5D.4070609@cygnus.com> References: <200110061257.f96CvtZ00321@delius.kettenis.local> <1011008225405.ZM9197@ocotillo.lan> X-SW-Source: 2001-10/msg00093.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.) Can I suggest keeping the two tasks separate. > 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. The unixware thread code has a number of potential cleanups (some of which would involve core changes). Since I don't think this will happen soon, I think Mark's suggestion should be persued regardless. Can, instead, the unixware code be localized to unixware files? If that is done I can ARI the macro's so that they don't infect new code. Andrew