Re: [RFC] ptid_get_pid function vs. PIDGET macro

Andrew Cagney
2001-10-09T22:28:00Z

> 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