From: Joel Brobecker <brobecker@adacore.com>
To: Emi SUZUKI <emi-suzuki@tjsys.co.jp>
Cc: gdb-patches@sourceware.org
Subject: Re: Watchpoint on an unloaded shared library(1)
Date: Sun, 21 Dec 2008 13:11:00 -0000 [thread overview]
Message-ID: <20081221131036.GB25416@adacore.com> (raw)
In-Reply-To: <20081216.211520.207584606.emi-suzuki@tjsys.co.jp>
> > How about replace all the code that's inside
> >
> > if (bpt->type == bp_watchpoint ||
> > bpt->type == bp_hardware_watchpoint ||
> > bpt->type == bp_read_watchpoint ||
> > bpt->type == bp_access_watchpoint)
> > {
> > [re-create a lot of stuff for our watchpoint...]
> >
> > by a call to update_watchpoint (bpt, 1)? Would that work in your case?
>
> It works without merging the missing code each other, as long as we
> don't have to care the hardware watchpoint resource count here: if the
> user sets other watchpoints while the disabled hardware watchpoints
> exist, re-enabling the disabled ones might fail out of the shortage of
> resources.
That's a good point.
I still think this might work. I am hanging on to the idea because
I'm seeing a few cases in this file where we have two pieces of code
that are almost the same and yet not quite the same. I really dislike
this code semi-duplication. I'm also seeing potential disasters such
as a reference to a free'ed value, which makes me want to share the
(correct!) code more.
So, what I think we should do, in this case, is call update_watchpoint
within an exception wrapper. If we fail to enable the watchpoint,
I think we want to print a message that's similar to the message
printed when re-setting it, something like this:
(gdb) enable 2
Cannot enable watchpoint 2: No symbol "sample_glob" in current context.
Rather than just printing:
(gdb) enable 2
No symbol "sample_glob" in current context.
If the update_watchpoint completes without exception, then there
are two cases:
1. The scope associated to the watchpoint no longer exists.
update_watchpoint has therefore "deleted" it, which actually
means has scheduled it for deletion at the next stop
(by setting b->disposition to disp_del_at_next_stop).
update_watchpoint has already printed an error message
about it, so there isn't much else to do.
2. Everything went fine in terms of updating the watchpoint.
We need to confirm that we still have enough hardware
resources to effectively insert the watchpoint.
So, in the end, the code should look like this:
if (bpt->type == bp_watchpoint ||
bpt->type == bp_hardware_watchpoint ||
bpt->type == bp_read_watchpoint ||
bpt->type == bp_access_watchpoint)
{
struct gdb_exception e;
TRY_CATCH (e, RETURN_MASK_ALL)
{
update_watchpoint (...);
}
if (e.reason < 0)
{
exception_fprintf (gdb_strerr, e, "Cannot enable watchpoint %d:",
b->number);
return;
}
else
{
[check hardware support here]
if (target_resources_ok < 0)
{
printf_filtered (error_message);
return;
}
}
}
Could you see if that works?
--
Joel
next prev parent reply other threads:[~2008-12-21 13:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-20 18:25 Emi SUZUKI
2008-12-13 15:06 ` Joel Brobecker
2008-12-16 12:16 ` Emi SUZUKI
2008-12-21 13:11 ` Joel Brobecker [this message]
2008-12-22 3:28 ` Joel Brobecker
2008-12-25 11:28 ` Emi SUZUKI
2008-12-26 6:11 ` Joel Brobecker
2008-12-26 7:09 ` Emi SUZUKI
2008-12-28 11:48 ` Joel Brobecker
2009-01-06 1:47 ` Emi SUZUKI
2009-01-06 4:28 ` Joel Brobecker
2009-01-06 5:16 ` Emi SUZUKI
2009-01-08 4:02 ` [commit] " Emi SUZUKI
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=20081221131036.GB25416@adacore.com \
--to=brobecker@adacore.com \
--cc=emi-suzuki@tjsys.co.jp \
--cc=gdb-patches@sourceware.org \
/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