From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH v2 3/5] Support buffer objects as handles in Inferior.thread_from_thread_handle()
Date: Thu, 28 Feb 2019 02:32:00 -0000 [thread overview]
Message-ID: <20190227193215.263e4b1d@f29-4.lan> (raw)
In-Reply-To: <20190227192416.613752c8@f29-4.lan>
InferiorThread.thread_handle() returns a python bytes object. We'd
like to be able to pass the output of thread_handle() to
Inferior.thread_from_thread_handle(). Up to now,
thread_from_thread_handle() expects to receive a gdb.Value input.
This commit adds support to also allow a python buffer object to be
passed as the handle.
infpy_thread_from_thread_handle() calls find_thread_by_handle() which
has the obvious functionality. It used to pass the thread handle via
a struct value pointer. I've revised this interface to instead pass a
gdb_byte pointer and length. I considered using a vector, but it
seemed more straightforward to just pass a pointer and length.
gdb/ChangeLog:
* gdbthread.h (find_thread_by_handle): Revise declaration.
* thread.c (find_thread_by_handle): Likewise. Adjust
implementation too.
* python/py-inferior.c (infpy_thread_from_thread_handle): Add
support for buffer objects as handles.
---
gdb/gdbthread.h | 3 ++-
gdb/python/py-inferior.c | 23 ++++++++++++++++++++---
gdb/thread.c | 8 +++-----
3 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/gdb/gdbthread.h b/gdb/gdbthread.h
index 7808569a8a..9a133eb45e 100644
--- a/gdb/gdbthread.h
+++ b/gdb/gdbthread.h
@@ -486,7 +486,8 @@ extern struct thread_info *find_thread_ptid (inferior *inf, ptid_t ptid);
struct thread_info *find_thread_global_id (int global_id);
/* Find thread by thread library specific handle in inferior INF. */
-struct thread_info *find_thread_by_handle (struct value *thread_handle,
+struct thread_info *find_thread_by_handle (const gdb_byte *thread_handle,
+ size_t handle_len,
struct inferior *inf);
/* Finds the first thread of the specified inferior. */
diff --git a/gdb/python/py-inferior.c b/gdb/python/py-inferior.c
index 72fbf6d90b..7e20343cfd 100644
--- a/gdb/python/py-inferior.c
+++ b/gdb/python/py-inferior.c
@@ -774,7 +774,25 @@ infpy_thread_from_thread_handle (PyObject *self, PyObject *args, PyObject *kw)
if (! gdb_PyArg_ParseTupleAndKeywords (args, kw, "O", keywords, &handle_obj))
return NULL;
- if (!gdbpy_is_value_object (handle_obj))
+ const gdb_byte *bytes;
+ size_t bytes_len;
+ Py_buffer_up buffer_up;
+ Py_buffer py_buf;
+
+ if (PyObject_CheckBuffer (handle_obj)
+ && PyObject_GetBuffer (handle_obj, &py_buf, PyBUF_SIMPLE) == 0)
+ {
+ buffer_up.reset (&py_buf);
+ bytes = (const gdb_byte *) py_buf.buf;
+ bytes_len = py_buf.len;
+ }
+ else if (gdbpy_is_value_object (handle_obj))
+ {
+ struct value *val = value_object_to_value (handle_obj);
+ bytes = value_contents_all (val);
+ bytes_len = TYPE_LENGTH (value_type (val));
+ }
+ else
{
PyErr_SetString (PyExc_TypeError,
_("Argument 'handle_obj' must be a thread handle object."));
@@ -785,9 +803,8 @@ infpy_thread_from_thread_handle (PyObject *self, PyObject *args, PyObject *kw)
TRY
{
struct thread_info *thread_info;
- struct value *val = value_object_to_value (handle_obj);
- thread_info = find_thread_by_handle (val, inf_obj->inferior);
+ thread_info = find_thread_by_handle (bytes, bytes_len, inf_obj->inferior);
if (thread_info != NULL)
return thread_to_thread_object (thread_info).release ();
}
diff --git a/gdb/thread.c b/gdb/thread.c
index 90999d3d0b..ac3d758c76 100644
--- a/gdb/thread.c
+++ b/gdb/thread.c
@@ -541,12 +541,10 @@ find_thread_ptid (inferior *inf, ptid_t ptid)
/* See gdbthread.h. */
struct thread_info *
-find_thread_by_handle (struct value *thread_handle, struct inferior *inf)
+find_thread_by_handle (const gdb_byte *thread_handle, size_t handle_len,
+ struct inferior *inf)
{
- return target_thread_handle_to_thread_info
- (value_contents_all (thread_handle),
- TYPE_LENGTH (value_type (thread_handle)),
- inf);
+ return target_thread_handle_to_thread_info (thread_handle, handle_len, inf);
}
/*
next prev parent reply other threads:[~2019-02-28 2:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-28 2:24 [PATCH v2 0/5] Add python method gdb.InferiorThread.thread_handle Kevin Buettner
2019-02-28 2:30 ` [PATCH v2 1/5] Introduce target_ops method thread_info_to_thread_handle Kevin Buettner
2019-03-05 21:44 ` Tom Tromey
2019-02-28 2:31 ` [PATCH v2 2/5] Add python method InferiorThread.thread_handle Kevin Buettner
2019-03-05 21:48 ` Tom Tromey
2019-03-20 20:24 ` Kevin Buettner
2019-03-20 20:39 ` Tom Tromey
2019-03-20 20:48 ` Kevin Buettner
2019-02-28 2:32 ` Kevin Buettner [this message]
2019-03-05 21:51 ` [PATCH v2 3/5] Support buffer objects as handles in Inferior.thread_from_thread_handle() Tom Tromey
2019-02-28 2:34 ` [PATCH v2 4/5] Tests for gdb.InferiorThread.thread_handle Kevin Buettner
2019-03-05 21:54 ` Tom Tromey
2019-02-28 2:35 ` [PATCH v2 5/5] Documentation for python method InferiorThread.thread_handle Kevin Buettner
2019-02-28 18:06 ` Eli Zaretskii
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=20190227193215.263e4b1d@f29-4.lan \
--to=kevinb@redhat.com \
--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