From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH/DOC RFA] Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto"
Date: Wed, 17 Sep 2014 13:49:00 -0000 [thread overview]
Message-ID: <54199160.5040500@redhat.com> (raw)
In-Reply-To: <8738bq1jcz.fsf@codesourcery.com>
On 09/17/2014 02:12 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
>
>> In hindsight, this "auto" setting was unnecessary, and not the ideal
>> solution. Non-stop mode does depends on breakpoints always-inserted
>> mode, but only as long as any thread is running. If no thread is
>> running, no breakpoint can be missed. The same is true for all-stop
>> too. E.g., if, in all-stop mode, and the user does:
>>
>> (gdb) c&
>> (gdb) b foo
>>
>> That breakpoint at "foo" should be inserted immediately, but it
>> currently isn't -- currently it'll end up inserted only if the target
>> happens to trip on some event, and is re-resumed, e.g., an internal
>> breakpoint triggers that doesn't cause a user-visible stop, and so we
>> end up in keep_going calling insert_breakpoints.
>>
>> IOW, no matter whether in non-stop or all-stop, if the target fully
>> stops, we can remove breakpoints. And no matter whether in all-stop
>> or non-stop, if any thread is running in the target, then we need
>> breakpoints to be immediately inserted. And then, if the target has
>
> Could we add some test cases for this? for example, breakpoint should be
> inserted immediately if any thread is running.
I'll try writing one. May need to skip all-stop/remote, as we can't
talk to the target if anything is running (blocked waiting for the vCont
reply).
>> +/* update_global_location_list's modes of operation wrt to whether to
>> + insert locations now. */
>> +enum ugll_insert_mode
>> +{
>> + /* Don't insert any breakpoint locations into the inferior, only
>> + remove already-inserted locations that no longer should be
>> + inserted. Functions that delete a breakpoint or breakpoints
>> + should specify this mode, so that deleting a breakpoint doesn't
>> + have the side effect of inserting the locations of other
>> + breakpoints that are marked not-inserted, but should_be_inserted
>> + returns true on them.
>> +
>> + This behavior is useful is situations close to tear-down -- e.g.,
>> + after an exec, while the target still has execution, but
>> + breakpoint shadows of the previous executable image should *NOT*
>> + be restored to the new image; or before detaching, where the
>> + target still has execution and wants to delete breakpoints from
>> + GDB's lists, and all breakpoints had already been removed from
>> + the inferior. */
>> + UGLL_DONT_INSERT,
>> +
>> + /* May insert breakpoints iff breakpoints_should_be_inserted_now
>> + claims breakpoints should be inserted now. */
>> + UGLL_MAY_INSERT,
>> +
>> + /* Insert locations now, even if breakpoints_should_be_inserted_now
>> + would return false. For example, no thread is resumed yet, but
>> + we're just about to resume the target. */
>> + UGLL_INSERT,
>> +};
>> +
>
> What does the last sentence in comments mean? "no thread is resumed
> yet, but we're just about to resume the target."
E.g., say everything all threads are stopped right now, and the user
does "continue". We need to insert breakpoints _before_ resuming the
target, but breakpoints_should_be_inserted_now returns false at
that point, as no thread is running. See where it's used:
@@ -2928,13 +2968,7 @@ insert_breakpoints (void)
update_watchpoint (w, 0 /* don't reparse. */);
}
- update_global_location_list (1);
-
- /* update_global_location_list does not insert breakpoints when
- always_inserted_mode is not enabled. Explicitly insert them
- now. */
- if (!breakpoints_always_inserted_mode ())
- insert_breakpoint_locations ();
+ update_global_location_list (UGLL_INSERT);
}
I'll try to clarify the comment of UGLL_INSERT, and I'll preserve this
comment in insert_breakpoints somehow instead of removing it completely.
> The patch looks good to me. However, IWBN to split it to two, patch 1
> is about refactor update_global_location_list and add enum ugll_insert_mode
> with only UGLL_DONT_INSERT and UGLL_MAY_INSERT. patch 2 does the rest.
I'll do that.
Thanks,
Pedro Alves
prev parent reply other threads:[~2014-09-17 13:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-17 0:26 Pedro Alves
2014-09-17 5:14 ` Eli Zaretskii
2014-09-17 13:16 ` Yao Qi
2014-09-17 13:49 ` Pedro Alves [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54199160.5040500@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox