This is the mail archive of the
mailing list for the GDB project.
Re: [patch] Add visible flag to breakpoints.
- From: Tom Tromey <tromey at redhat dot com>
- To: pmuldoon at redhat dot com
- Cc: Pedro Alves <pedro at codesourcery dot com>, gdb-patches at sourceware dot org, dan at codesourcery dot com
- Date: Fri, 08 Oct 2010 12:44:24 -0600
- Subject: Re: [patch] Add visible flag to breakpoints.
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
>>>>> "Phil" == Phil Muldoon <email@example.com> writes:
Pedro> I would also suggest using a VEC for the breakpoints instead
Pedro> of a linked list.
Pedro> (Also, the old code appeared to have been designed for O(1) access to
Pedro> the python breakpoint objects given a breakpoing number: I have no
Pedro> clue it if that matters but you could preserve that easily with two
Pedro> VECs or bppy_breakpoints arrays.)
Phil> Yeah the old code used vectors, and I converted it to a linked list to
Phil> cope with negative breakpoint numbers. I did consider keeping two
Phil> vectors. But I wasn't sure if the 0(1) design choice was conscious for
Phil> performance or whether it was just done that way.
It was, but I am not sure that it matters.
Phil> FWIW we only track
Phil> user watchpoints and breakpoints (and now the special breakpoint we have
Phil> introduced). Even in a potentially heavy situation I would expect the
Phil> number of user breakpoints to be < 1000? Is it really necessary? It's a
Phil> trade-off of for keeping two reallocated vectors over the lifetime to
Phil> maintaining a linked list. I'm ambivalent to how we decide to do it. I
Phil> just wanted to explain my rationale.
Why don't we just put a reference to the PyObject into struct
breakpoint? This solves the problem completely, or at least pushes it
up to whatever algorithms are used in breakpoint.c. This can easily be
done in a way that does not break the Python-less case (see varobj.c for