Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Phil Muldoon <pmuldoon@redhat.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org, dan@codesourcery.com
Subject: Re: [patch] Add visible flag to breakpoints.
Date: Fri, 08 Oct 2010 14:04:00 -0000	[thread overview]
Message-ID: <m3zkuo3hmy.fsf@redhat.com> (raw)
In-Reply-To: <201010081435.15174.pedro@codesourcery.com> (Pedro Alves's	message of "Fri, 8 Oct 2010 14:35:14 +0100")

Pedro Alves <pedro@codesourcery.com> writes:

> On Friday 08 October 2010 13:50:34, Phil Muldoon wrote:
>> The @var{internal} argument has no effect with watchpoints.
>
> Should it be an error instead (or made to work)?

I can make it an error.  I decided not to do watchpoints.  The
consequences of setting hidden watchpoints from a script that could turn
out to be software watchpoints seemed a little troubling. 

> The non-python bits looked fine.  I'd prefer Tom or someone
> else to look and approve those.  I did notice:
>
>>  #define BPPY_REQUIRE_VALID(Breakpoint)                                 \
>>      do {                                                               \
>> -      if (! bpnum_is_valid ((Breakpoint)->number))                     \
>> +      if (Breakpoint == NULL)                                          \
>>         return PyErr_Format (PyExc_RuntimeError, _("Breakpoint %d is invalid."), \
>>                              (Breakpoint)->number);                     \

> '(Breakpoint)->number' when Breakpoint is NULL is not going to work.

Oops, thanks for catching that.  (Breakpoint)->number is left over from
the old macro.  Will fix.

> Also, missing ()s:
>
>      if ((Breakpoint) == NULL)

Thanks.

> I would also suggest using a VEC for the breakpoints instead
> of a linked list.
>
> (Also, the old code appeared to have been designed for O(1) access to
> the python breakpoint objects given a breakpoing number: I have no
> clue it if that matters but you could preserve that easily with two
> VECs or bppy_breakpoints arrays.)

Yeah the old code used vectors, and I converted it to a linked list to
cope with negative breakpoint numbers.  I did consider keeping two
vectors.  But I wasn't sure if the 0(1) design choice was conscious for
performance or whether it was just done that way.  FWIW we only track
user watchpoints and breakpoints (and now the special breakpoint we have
introduced).  Even in a potentially heavy situation I would expect the
number of user breakpoints to be < 1000?  Is it really necessary?  It's a
trade-off of for keeping two reallocated vectors over the lifetime to
maintaining a linked list.  I'm ambivalent to how we decide to do it.  I
just wanted to explain my rationale.

Cheers,

Phil


  reply	other threads:[~2010-10-08 14:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-30 16:28 Phil Muldoon
2010-09-30 16:41 ` Daniel Jacobowitz
2010-09-30 17:51   ` Phil Muldoon
2010-09-30 17:55     ` Pedro Alves
2010-09-30 18:12       ` Phil Muldoon
2010-10-08 12:51       ` Phil Muldoon
2010-10-08 13:35         ` Pedro Alves
2010-10-08 14:04           ` Phil Muldoon [this message]
2010-10-08 18:44             ` Tom Tromey
2010-10-12 20:25               ` Phil Muldoon
2010-10-12 21:34                 ` Tom Tromey
2010-10-13 12:45                   ` Phil Muldoon
2010-10-13 13:06                     ` Phil Muldoon
2010-10-13 15:36                     ` Tom Tromey
2010-10-16 18:42                     ` Pedro Alves
2010-10-16 19:03             ` Pedro Alves
2010-10-18 16:09               ` Tom Tromey
2010-10-22 21:05                 ` Phil Muldoon
2010-10-22 21:31                   ` Eli Zaretskii
2010-10-22 21:37                     ` Phil Muldoon
2010-10-23  9:07                       ` Eli Zaretskii
2010-10-31 21:07                   ` Pedro Alves
2010-11-11 14:36                     ` Phil Muldoon
2010-11-12 12:43                       ` Ken Werner
2010-11-12 12:49                         ` Pedro Alves
2010-11-12 12:58                           ` Ken Werner
2010-10-08 18:40         ` Tom Tromey
2010-09-30 17:04 ` Pedro Alves
2010-09-30 17:55   ` Phil Muldoon
2010-09-30 17:51 ` Eli Zaretskii
2010-10-05 22:28 ` Tom Tromey

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=m3zkuo3hmy.fsf@redhat.com \
    --to=pmuldoon@redhat.com \
    --cc=dan@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@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