From: Phil Muldoon <pmuldoon@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Doug Evans <dje@google.com>,
pedro@codesourcery.com, eliz@gnu.org,
gdb-patches@sourceware.org
Subject: Re: [patch] Add an evaluation function hook to Python breakpoints.
Date: Thu, 27 Jan 2011 12:44:00 -0000 [thread overview]
Message-ID: <m3k4hqznrw.fsf@redhat.com> (raw)
In-Reply-To: <m3mxo6lpyi.fsf@fleche.redhat.com> (Tom Tromey's message of "Wed, 15 Dec 2010 13:51:33 -0700")
Tom Tromey <tromey@redhat.com> writes:
>>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
Sorry for the delay in replying. I just noticed this email has been
pending for awhile.
> Phil> + struct cleanup *cleanup = ensure_python_env (get_current_arch (),
> Phil> + current_language);
>
> I didn't notice this before. I think this should use the breakpoint's
> arch and language.
Two odd things I noticed here. ensure_python_env requires:
const struct language_defn *language
But struct breakpoint only stores:
language_defn->la_language
So we only have the enum la_language available when we have the
breakpoint. Not sure if there is a way to backtrack back to
language_defn, and if not, we are stuck with current_language.
Also the b->gdbarch member is NULL with watchpoints, so we have to do:
PyObject *py_bp = (PyObject *) bp_obj;
struct breakpoint *b = bp_obj->bp;
struct gdbarch *garch = b->gdbarch ? b->gdbarch : get_current_arch ();
struct cleanup *cleanup = ensure_python_env (garch, current_language);
I'm not sure why watchpoints have a NULL gdbarch, but if you grep
watch_command_1, the watchpoint is eventually created with:
/* Now set up the breakpoint. */
b = set_raw_breakpoint_without_location (NULL, bp_type);
Where that NULL is the architecture. It never seems to be updated.
Anyway we need the architecture later when we call
convert_value_from_python. Without it we get:
Program received signal SIGSEGV, Segmentation fault.
0x00000000005a99ab in gdbarch_data (gdbarch=0x0, data=0xbb1820) at ../../archer/gdb/gdbarch.c:3924
3924 gdb_assert (data->index < gdbarch->nr_data);
(gdb) bt
#0 0x00000000005a99ab in gdbarch_data (gdbarch=0x0, data=0xbb1820) at ../../archer/gdb/gdbarch.c:3924
#1 0x00000000005b3a74 in builtin_type (gdbarch=0x0) at ../../archer/gdb/gdbtypes.c:3650
#2 0x000000000050ef84 in convert_value_from_python (obj=0xc93ff0) at ../../archer/gdb/python/py-value.c:1116
#3 0x000000000050e86a in valpy_richcompare (self=0x7ffff202ee30, other=0xc93ff0, op=2) at ../../archer/gdb/python/py-value.c:907
> Phil> + if (PyObject_HasAttrString (py_bp, method))
> Phil> + {
> Phil> + PyObject *result = PyObject_CallMethod (py_bp, method, NULL);
>
> Since we're now overloading the "condition" member, what happens if the
> user sets a condition on the breakpoint?
>
> I think we may need an additional check here, to see if the "condition"
> member is a callable object.
I cannot find a way to test if an attribute is callable or
not. There is: PyCallable_Check but that only refers to the object
itself. I think there is only a check to see if the attribute exists
(which we do), but as you correctly point out, as we are overloading
"condition" that will always return True. For now, as we are waiting
for other bits of the breakpoint puzzle to fall in place, I've returned
the name to "eval". It is trivial to change it in the code and tests at
a later date.
Cheers
Phil
next prev parent reply other threads:[~2011-01-27 9:42 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-13 13:50 Phil Muldoon
2010-12-13 14:19 ` Eli Zaretskii
2010-12-13 14:47 ` Phil Muldoon
2010-12-13 15:07 ` Eli Zaretskii
2010-12-13 17:21 ` Phil Muldoon
2010-12-13 17:46 ` Eli Zaretskii
2010-12-13 14:33 ` Pedro Alves
2010-12-13 14:56 ` Phil Muldoon
2010-12-13 15:07 ` Pedro Alves
2010-12-13 20:45 ` Doug Evans
2010-12-13 21:02 ` Phil Muldoon
2010-12-14 3:31 ` Doug Evans
2010-12-14 17:18 ` Phil Muldoon
2010-12-14 17:28 ` Tom Tromey
2010-12-14 19:51 ` Phil Muldoon
2010-12-14 20:00 ` Phil Muldoon
2010-12-15 15:34 ` Phil Muldoon
2010-12-15 20:51 ` Tom Tromey
2011-01-27 12:44 ` Phil Muldoon [this message]
[not found] ` <AANLkTimi6ugruNAqUGHni8Kvkz+B5-s2aAkEoTY2D_gT@mail.gmail.com>
2011-01-27 21:40 ` Phil Muldoon
2011-01-28 10:42 ` Tom Tromey
2010-12-15 16:21 ` Doug Evans
2010-12-15 20:57 ` Tom Tromey
2010-12-21 17:33 ` Doug Evans
2010-12-21 20:02 ` Tom Tromey
2010-12-22 16:34 ` Doug Evans
2010-12-22 17:35 ` Tom Tromey
2010-12-28 5:53 ` Doug Evans
2011-01-05 18:35 ` Tom Tromey
2011-01-05 20:23 ` Phil Muldoon
2011-01-09 20:32 ` Doug Evans
2010-12-14 17:46 ` Pedro Alves
2010-12-14 16:35 ` Tom Tromey
2010-12-14 17:02 ` Phil Muldoon
2010-12-14 17:48 ` Tom Tromey
2010-12-14 16:42 ` 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=m3k4hqznrw.fsf@redhat.com \
--to=pmuldoon@redhat.com \
--cc=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.com \
--cc=tromey@redhat.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