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: [PATCH 4/7] range stepping: gdb


On 05/15/2013 09:07 AM, Yao Qi wrote:

>> I dislike the design of using PC checks here too :-/.  That
>> seems fragile, and potentially inefficient (considering GDB ever
>> sending more than one range action per packet, that might end up
>> fetching registers for threads unnecessarily).  IMO, it's better to have
> 
> Sorry, I don't understand why it is inefficient.

I meant, thinking forward, if GDB ever sends 100 vCont;r's in the same packet,
checking the PC potentially forces fetching the current registers for
100 threads, if GDB doesn't have them (or no longer has them) cached at that
point, with the associated extra RSP rountrips/traffic that causes.  It seems
better not to have a design that forces this refetch.

The fragility aspect was a much stronger concern though.
I ran the testsuite with an assertion in remote.c to catch the cases
of when the PC would be out of the step range.  It caught things like
displaced stepping, stepping through the dynamic linker, stepping through
inlines, and probably others I don't recall right now.  Along with software
watchpoints, this made wary of other cases (not controlled by trap_expected)
where complex run control might end up requiring the target reporting
a stop after a single instruction step even if the thread was in the
step range to begin with.

-- 
Pedro Alves


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