Re: [RFC] ptid_get_pid function vs. PIDGET macro

[Andrew Cagney <ac131313 at cygnus dot com>]

> 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