[RFC] ptid_get_pid function vs. PIDGET macro

[RFC] ptid_get_pid function vs. PIDGET macro

[Mark Kettenis]

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?

Mark

Re: [RFC] ptid_get_pid function vs. PIDGET macro

[Kevin Buettner]

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

Re: [RFC] ptid_get_pid function vs. PIDGET macro

[Andrew Cagney]

> 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

Re: [RFC] ptid_get_pid function vs. PIDGET macro

[Kevin Buettner]

On Oct 10,  1:27am, Andrew Cagney wrote:

> > 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.

I think it's already fairly localized.  There are some places in
generic code which call PIDGET and TIDGET, but now that I think about
it some more, it'd probably be okay to convert / deprecate these.  The
files that should NOT be converted are config/i386/tm-i386v42mp.h and
uw-thread.c.  So long as we avoid touching these two files (until such
time that these are properly fixed), I withdraw my objection to Mark's
proposal that we deprecate PIDGET, TIDGET, and MERGEPID in the rest of
the sources.

Mark, did you want to do this?  Or should I whip up a perl script?

Kevin

Re: [RFC] ptid_get_pid function vs. PIDGET macro

[Mark Kettenis]

   Date: Wed, 10 Oct 2001 00:00:55 -0700
   From: Kevin Buettner <kevinb@cygnus.com>

   Mark, did you want to do this?  Or should I whip up a perl script?

I intended to do things by hand, gradually converting the source files
whenever I felt like it.  I did change thread-db.c some time ago and
since I wanted to make some further changes to it, I wondered whether
I should throw away these changes or not.  I'll commit the changes
somewehere in the near future.

Mark