From: "Willgerodt, Felix" <felix.willgerodt@intel.com>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH 09/10] btrace, python: Enable calling the ptwrite listener.
Date: Mon, 14 Jun 2021 14:53:13 +0000 [thread overview]
Message-ID: <1dfc3bde7dd14d2a87015e1c31a5191c@intel.com> (raw)
In-Reply-To: <A78C989F6D9628469189715575E55B236B43FD68@IRSMSX104.ger.corp.intel.com>
On 6/4/19 2:37 PM, Metzger, Markus T wrote:
> Hello Felix,
>
>> diff --git a/gdb/btrace.h b/gdb/btrace.h
>> index 7a80f5a44e1..7ad3cb65a28 100644
>> --- a/gdb/btrace.h
>> +++ b/gdb/btrace.h
>> @@ -354,6 +354,14 @@ struct btrace_thread_info
>> stepping through the execution history. */
>> std::vector<std::string> aux_data;
>>
>> + /* Function pointer to the ptwrite callback. Returns the string returned
>> + by the ptwrite listener function or nullptr if no string is supposed to
>> + be printed. */
>> + gdb::unique_xmalloc_ptr<char> (*ptw_callback_fun) (
>> +const uint64_t *payload,
>> +const uint64_t *ip,
>> +const void *ptw_listener);
>> +
>> /* PyObject pointer to the ptwrite listener function. */
>> void *ptw_listener = nullptr;
>>
>> diff --git a/gdb/python/py-record-btrace.c b/gdb/python/py-record-btrace.c
>> index c7ad47d64a0..42a0c29a348 100644
>> --- a/gdb/python/py-record-btrace.c
>> +++ b/gdb/python/py-record-btrace.c
>> @@ -772,6 +772,68 @@ recpy_bt_function_call_history (PyObject *self, void
>> *closure)
>> return btpy_list_new (tinfo, first, last, 1, &recpy_func_type);
>> }
>>
>> +/* Calling the ptwrite listener. Returns a pointer to the string that will be
>> + printed or nullptr if nothing should be printed. */
>> +gdb::unique_xmalloc_ptr<char>
>> +recpy_call_listener (const uint64_t *payload, const uint64_t *ip,
>> + const void *ptw_listener)
>> +{
>> + if ((PyObject *) ptw_listener == Py_None)
>> + return nullptr;
>> + else if ((PyObject *) ptw_listener == nullptr)
>> + error (_("No valid ptwrite listener."));
Markus> PTW_LISTENER is declared void * in struct btrace_info. Couldn't we treat nullptr
Markus> as not-present?
If ptw_listener is a nullptr, something went rather wrong. We have a listener active by
default and can only "deactivate" the listener by registering Py_None. I don't think this
extra check hurts. But I don't have a strong opinion if you want it removed.
>> +
>> + /* As Python is started as a seperate thread, we need to
>> + acquire the GIL to safely call the listener function. */
>> + PyGILState_STATE gstate = PyGILState_Ensure ();
>> +
>> + PyObject *py_ip = Py_None;
>> + PyObject *py_payload = PyLong_FromUnsignedLongLong (*payload);
>> + Py_INCREF (Py_None);
Markus> Are we dropping that reference again in the case that PY_IP gets overwritten?
We are now, thanks.
>> +
>> + if (ip != nullptr)
>> + py_ip = PyLong_FromUnsignedLongLong (*ip);
Markus> It wouldn't hurt to document that IP can be NULL whereas PAYLOAD cannot
Markus> in the function's comment.
Done
>> +
>> + PyObject *py_result = PyObject_CallFunctionObjArgs ((PyObject *)
>> ptw_listener,
>> + py_payload, py_ip, NULL);
>> +
>> + if (PyErr_Occurred ())
>> + {
>> + gdbpy_print_stack ();
>> + gdb_Py_DECREF (py_ip);
>> + gdb_Py_DECREF (py_payload);
>> + gdb_Py_DECREF (py_result);
>> + PyGILState_Release (gstate);
>> + error (_("Error while executing Python code."));
>> + }
>> +
>> + gdb_Py_DECREF (py_ip);
>> + gdb_Py_DECREF (py_payload);
>> +
>> + if (py_result == Py_None)
>> + {
>> + gdb_Py_DECREF (py_result);
>> + PyGILState_Release (gstate);
>> + return nullptr;
>> + }
>> +
>> + gdb::unique_xmalloc_ptr<char> resultstring = gdbpy_obj_to_string
>> (py_result);
>> +
>> + if (PyErr_Occurred ())
>> + {
>> + gdbpy_print_stack ();
>> + gdb_Py_DECREF (py_result);
>> + PyGILState_Release (gstate);
>> + error (_("Error while executing Python code."));
>> + }
>> +
>> + if (py_result != nullptr)
>> + gdb_Py_DECREF (py_result);
Markus> Shouldn't we check that before using PY_RESULT above?
I removed the check as it shouldn't be necessary at all.
PyObject_CallFunctionObjArgs only returns nullptr if an error occured,
but that is already checked via PyErr_Occurred ().
Thanks,
Felix
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2021-06-14 14:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 8:48 [PATCH 00/10] Extensions for PTWRITE felix.willgerodt
2019-05-29 8:48 ` [PATCH 06/10] python: Add clear_trace() to gdb.Record felix.willgerodt
2019-05-29 14:41 ` Eli Zaretskii
2019-06-04 12:36 ` Metzger, Markus T
2021-06-14 14:53 ` Willgerodt, Felix
2019-05-29 8:48 ` [PATCH 03/10] btrace: Enable auxiliary instructions in record function-call-history felix.willgerodt
2019-05-29 14:40 ` Eli Zaretskii
2019-06-04 12:35 ` Metzger, Markus T
2021-06-14 14:53 ` Willgerodt, Felix
2021-06-16 9:13 ` Metzger, Markus T
2021-06-16 10:03 ` Willgerodt, Felix
2021-06-16 10:16 ` Metzger, Markus T
2019-05-29 8:48 ` [PATCH 09/10] btrace, python: Enable calling the ptwrite listener felix.willgerodt
2019-06-04 12:37 ` Metzger, Markus T
2021-06-14 14:53 ` Willgerodt, Felix [this message]
2019-05-29 8:48 ` [PATCH 08/10] btrace, python: Enable ptwrite listener registration felix.willgerodt
2019-06-04 12:36 ` Metzger, Markus T
2021-06-14 14:53 ` Willgerodt, Felix
2019-05-29 8:48 ` [PATCH 07/10] btrace, linux: Enable ptwrite packets felix.willgerodt
2019-06-04 12:36 ` Metzger, Markus T
2021-06-14 14:53 ` Willgerodt, Felix
2019-05-29 8:48 ` [PATCH 02/10] btrace: Enable auxiliary instructions in record instruction-history felix.willgerodt
2019-06-04 12:35 ` Metzger, Markus T
2021-06-14 14:53 ` Willgerodt, Felix
2019-05-29 8:48 ` [PATCH 04/10] btrace: Handle stepping and goto for auxiliary instructions felix.willgerodt
2019-06-04 12:35 ` Metzger, Markus T
2021-06-14 14:53 ` Willgerodt, Felix
2019-05-29 8:48 ` [PATCH 01/10] btrace: Introduce " felix.willgerodt
2019-05-29 14:39 ` Eli Zaretskii
2019-06-04 12:35 ` Metzger, Markus T
2019-05-29 8:48 ` [PATCH 10/10] btrace: Extend event decoding for ptwrite felix.willgerodt
2019-05-29 14:53 ` Eli Zaretskii
2019-06-04 12:37 ` Metzger, Markus T
2021-06-14 14:53 ` Willgerodt, Felix
2019-05-29 8:48 ` [PATCH 05/10] python: Introduce gdb.RecordAuxiliary class felix.willgerodt
2019-05-29 14:42 ` Eli Zaretskii
2019-06-04 12:36 ` Metzger, Markus T
2021-06-14 14:53 ` Willgerodt, Felix
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=1dfc3bde7dd14d2a87015e1c31a5191c@intel.com \
--to=felix.willgerodt@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=markus.t.metzger@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).