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] |
Date: Thu, 05 Jan 2012 12:55:58 -0200 From: Luis Machado<luis_gustavo@mentor.com>
This patch series adds support and required machinery to enable breakpoint condition evaluation on the stub's side instead of solely in the host's side.
When the evaluation is done on the stub's side, we eliminate all the useless stub -> GDB trap notifications that happen when the condition is false, potentially improving the speed of debugging on slower connections.But the downside is that the stub has more work to do, and therefore can potentially disrupt the timeline of the program being debugged. Is this feature really worth it? How "slow" should a slow connection be before this becomes a win? are there types of programs where this mode should never be used for fear of interfering with the program's timings?
In this case, the old behavior is kept intact with mode "gdb". I'm ok with keeping it that way, for the sake of potentially slow targets. We can always reconsider this at a later stage.A new switch was added to make it possible to choose between gdb/stub evaluation modes: set/show breakpoint condition-evaluation. It defaults to "auto". "auto" means "gdb" whenever the stub can't handle breakpoint condition evaluation or when the expression can't be evaluated by the agent expression machinery. "auto" means "stub" when the remote stub supports evaluating conditions and if the expressions generate valid agent expression bytecodes.Isn't it better to make the default be "off", i.e. keep the previous modus operandi?
Luis lgustavo@codesourcery.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |