This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 00/10] Remove standalone ptid functions
- From: Tom Tromey <tom at tromey dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: Pedro Alves <palves at redhat dot com>, Simon Marchi <simon dot marchi at polymtl dot ca>, Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org
- Date: Mon, 02 Jul 2018 09:00:45 -0600
- Subject: Re: [RFA 00/10] Remove standalone ptid functions
- References: <20180613215049.9691-1-tom@tromey.com> <20180613232228.GA2166@adacore.com> <49903166aff66528df83fbda26001be8@polymtl.ca> <64e82c8f-9647-2fb9-62f7-0b31660a41c6@redhat.com> <87bmcde5nq.fsf@tromey.com>
>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:
>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
Pedro> I'm just not so sure about eliminating pid_to_ptid. I'd ran into uses
Pedro> of that where I had second thoughts on whether replacing it with
Pedro> a ptid_t ctor call is really a good idea. What I thought was,
Pedro> that when you're reading the code, a pid_to_ptid call more clearly shows
Pedro> that want to build a process-wide (sometimes a filter) ptid as opposed
Pedro> to a single thread ptid. It also helps with grepping, if you'd like
Pedro> to find such spots. But it's not a big deal, and I can certainly live
Pedro> with it.
Tom> It's easy enough to drop it out of the series if you would prefer that,
Tom> or to rename it to something like ptid_t::from_pid. Let me know.
Hi Pedro. This series is still pending since I was waiting for a reply
to this.
Tom