From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22602 invoked by alias); 6 Jan 2012 08:47:06 -0000 Received: (qmail 22593 invoked by uid 22791); 6 Jan 2012 08:47:05 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_WEB,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Jan 2012 08:46:51 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LXD00L00CDCTE00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Fri, 06 Jan 2012 10:46:50 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.16.185]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LXD00G27CE1VZS2@a-mtaout22.012.net.il>; Fri, 06 Jan 2012 10:46:49 +0200 (IST) Date: Fri, 06 Jan 2012 08:47:00 -0000 From: Eli Zaretskii Subject: Re: [RFC stub-side break conditions 3/5] GDB-side changes In-reply-to: <4F05BA10.3090107@mentor.com> To: luis_gustavo@mentor.com Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83y5tlnrsx.fsf@gnu.org> References: <4F05BA10.3090107@mentor.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00231.txt.bz2 > Date: Thu, 05 Jan 2012 12:56:16 -0200 > From: Luis Machado > > This machinery works by marking locations modified through the > "condition_changed" field. Conditions change whenever we create a new > location, use the "condition" command or delete an old duplicate > location. Furthermore, if a location at addr 0xdeadbeef had its > condition modified, all duplicate locations at 0xdeadbeef are marked > modified as well. > > The modification detection takes place inside > update_global_location_list (...). By calling > force_breakpoint_reinsertion (...), we mark every location at address > 0xdeadbeef as modified. When consolidating the final updated list of > locations, we detect these locations and mark the non-duplicate location > at 0xdeafbeef as "needs_update". > > The "needs_update" field is used during breakpoint insertion. It forces > insertion of breakpoints even if they are marked as inserted already. > > Now that we have information about locations that we should reinsert in > the target, we proceed to build a list of hex-encoded agent expressions. > > At this point, if any conditional expressions fail to parse to a valid > agent expression, we assume that the conditions will be evaluated on > GDB's side. Thus we don't send the conditions to the stub. Otherwise, we > proceed to insert the breakpoints and the remote code now attaches the > hex-encoded expressions to the z0/z1 packet. > > Regarding always-inserted mode, if it is "on" we must send condition > changes right away, or else the target will potentially miss breakpoint > hits. If always-inserted is "off", this isn't too critical, so we just > wait for the insertion call to send all the conditions to the stub. We > will remove them when stopping anyway. WIBNI these details were somewhere in the source comments or (gasp!) in gdbint.texinfo? > +/* Shows the current mode of breakpoint condition evaluation. Explicitly shows > + what "auto" is translating to. */ > + > +static void > +show_condition_evaluation_mode (struct ui_file *file, int from_tty, > + struct cmd_list_element *c, const char *value) > +{ > + if (condition_evaluation_mode == condition_evaluation_auto) > + fprintf_filtered (file, > + _("Breakpoint condition evaluation " > + "mode is %s (currently %s).\n"), > + value, > + breakpoint_condition_evaluation_mode ()); > + else > + fprintf_filtered (file, _("Breakpoint condition evaluation mode is %s.\n"), > + value); > +} > + Is it a good idea to show "gdb" or "stub" rather than "auto"? After all, as you explained elsewhere, the translation is not 100% accurate, depending on the specifics of each individual condition. > + /* Print whether the remote stub is doing the breakpoint's condition > + evaluation. If GDB is doing the evaluation, don't print anything. */ > + if (loc && is_breakpoint (b) && loc->cond_bytecode > + && breakpoint_condition_evaluation_mode () > + != condition_evaluation_gdb) > + { > + ui_out_text (uiout, " ("); > + ui_out_field_string (uiout, "condeval", > + breakpoint_condition_evaluation_mode ()); I suggest "cond.eval." instead of "condeval". Better yet, how about "evaluated by"? > -address and file/line number respectively.\n\ > +breakpoint will be disabled. The \"Address\" and \"What\" columns indicate\n\ > +the address and file/line number respectively. The \"Cond Eval\" column\n\ ^^ Need two spaces here. > -address and file/line number respectively.\n\ > +breakpoint will be disabled. The \"Address\" and \"What\" columns indicate\n\ > +the address and file/line number respectively. The \"Cond Eval\" column\n\ Likewise. > -address and file/line number respectively.\n\ > +breakpoint will be disabled. The \"Address\" and \"What\" columns indicate\n\ > +the address and file/line number respectively. The \"Cond Eval\" column\n\ Likewise. > -address and file/line number respectively.\n\ > +breakpoint will be disabled. The \"Address\" and \"What\" columns indicate\n\ > +the address and file/line number respectively. The \"Cond Eval\" column\n\ Likewise. > + add_setshow_enum_cmd ("condition-evaluation", class_breakpoint, > + condition_evaluation_enums, > + &condition_evaluation_mode, _("\ > +Set mode for breakpoint condition evaluation."), _("\ "Set mode of breakpoint condition evaluation". "Of", not "for". And the same for "Show". > +and conditions will be evaluated on the target's side by the remote stub. If\n\ ^^ Two spaces. > +this is set to \"auto\" (default), this setting will be automatically set\n\ "setting with be ... set" is not the best style. Just "this will be automatically set" is better. Btw, what happens if I set the mode to "stub" and the sub does not support this? Do I get any feedback, and if so, at what time? Thanks.