This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 4/7] range stepping: gdb
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 20 May 2013 18:59:28 +0100
- Subject: Re: [PATCH 4/7] range stepping: gdb
- References: <1363006291-13334-1-git-send-email-yao at codesourcery dot com> <1363006291-13334-5-git-send-email-yao at codesourcery dot com> <51928303 dot 3050407 at redhat dot com> <51934234 dot 9090707 at codesourcery dot com>
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