This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA 00/10] Remove standalone ptid functions


On 06/14/2018 03:04 AM, Simon Marchi wrote:
> On 2018-06-13 19:22, Joel Brobecker wrote:
>>> This series removes the remaining standalone ptid functions in favor
>>> of using methods on ptid_t.
>>>
>>> These patches were largely created by running a script.
>>
>> Looks like a very nice cleanup. I scanned through some of the patches,
>> but not being the C++ expert in the group, I only did it out of
>> curiosity for now. It looks fairly mechanical, as hinted by the fact
>> that Tom said it was created by running a script.
>>
>> Anyone against the idea behind the change itself? Otherwise, I'd be
>> inclined to allow Tom to self-review on that one.
>>
>> Thanks Tom!
> 
> Yay, thanks Tom, I did not have the courage to do that!  I was just waiting for Pedro to eliminate ptid_t completely with his multi-target work :).

I won't eliminate it completely.  :-)

> I sampled a few files, and it LGTM.  I also built the cross-compiled Linux configurations I have, and it went fine.  If there's a compilation failure resulting from this, it should be very easy to fix.

I'm fine with this.

I'm just not so sure about eliminating pid_to_ptid.  I'd ran into uses
of that where I had second thoughts on whether replacing it with
a ptid_t ctor call is really a good idea.  What I thought was,
that when you're reading the code, a pid_to_ptid call more clearly shows
that want to build a process-wide (sometimes a filter) ptid as opposed
to a single thread ptid.  It also helps with grepping, if you'd like
to find such spots.  But it's not a big deal, and I can certainly live
with it.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]