From: Pedro Alves <palves@redhat.com>
To: "Blanc, Nicolas" <nicolas.blanc@intel.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Stale breakpoint instructions, spurious SIGTRAPS.
Date: Wed, 23 Apr 2014 16:27:00 -0000 [thread overview]
Message-ID: <5357E9EB.9090005@redhat.com> (raw)
In-Reply-To: <388084C8C1E6A64FA36AD1D656E4856635AE8EB5@IRSMSX106.ger.corp.intel.com>
On 04/16/2014 06:18 PM, Blanc, Nicolas wrote:
> Hi Pedro,
>
>> Then, the reason that disable_breakpoints_in_freed_objfile was clearing the inserted flag isn't clear, but likely to avoid breakpoint removal errors, assuming remove-symbol-file was called after the dynamic object was already unmapped from the inferior.
>
> Indeed that was the intend. The clearing of the flag copied from disable_breakpoints_in_unloaded_shlib.
I see.
>
>> if (val)
>> @@ -7666,7 +7693,7 @@ disable_breakpoints_in_freed_objfile (struct objfile *objfile)
>> ? /* If the file is a shared library not loaded by the user then
>> solib_unloaded was notified and disable_breakpoints_in_unloaded_shlib
>> was called. In that case there is no need to take action again. */
>> - if ((objfile->flags & OBJF_SHARED) && !(objfile->flags & OBJF_USERLOADED))
>> + if ((objfile->flags & OBJF_USERLOADED) == 0)
>> return;
>
> The comment above should be updated. The condition is now weaker.
I've updated the comment.
>
>
> ALL_BREAKPOINTS (b)
> @@ -7698,7 +7725,11 @@ disable_breakpoints_in_freed_objfile (struct objfile *objfile)
>> if (is_addr_in_objfile (loc_addr, objfile))
>> {
>> loc->shlib_disabled = 1;
>> - loc->inserted = 0;
>> + /* At this point, we don't know whether the object was
>> + unmapped from the inferior or not, so leave the
>> + inserted flag alone. We'll handle failure to
>> + uninsert quietly, in case the object was indeed
>> + unmapped. */
>
> Would it work to simplify disable_breakpoints_in_unloaded_shlib in the same way?
> Note that I understand it might be unnecessary risky to fix a function that is not broken.
Yeah. In fact, it seems to me that by just clearing the
inserted flag, we leave stale HW breakpoints planted in the target,
just like in the "remove-symbol-file" case. So we should either fix
it in the same way, or only clear the flag for software breakpoints.
>
>> + /* Make sure we see the memory breakpoints. */ cleanup =
>> + make_show_memory_breakpoints_cleanup (1); val = target_read_memory
>> + (addr, old_contents, bplen);
>
> It was not immediately clear to me that old_contents means current content.
Indeed. I had just copied this from ppc_linux_memory_remove_breakpoint
and not noticed that. I've renamed it in the version pushed.
Thanks,
--
Pedro Alves
prev parent reply other threads:[~2014-04-23 16:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 18:18 Pedro Alves
2014-04-16 3:22 ` Yao Qi
2014-04-23 16:20 ` [pushed] " Pedro Alves
[not found] ` <388084C8C1E6A64FA36AD1D656E4856635AE8EB5@IRSMSX106.ger.corp.intel.com>
2014-04-23 16:27 ` 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=5357E9EB.9090005@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=nicolas.blanc@intel.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