From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH][gdb/tdep] Use pid to choose x86_64 process 64/32-bitness
Date: Fri, 7 May 2021 10:44:04 +0200 [thread overview]
Message-ID: <20210507084402.GA14817@delia> (raw)
Hi,
In a linux kernel mailing list discussion, it was mentioned that "gdb has
this odd thing where it takes the 64-bit vs 32-bit data for the whole process
from one thread, and picks the worst possible thread to do it (ie explicitly
not even the main thread, ...)" [1].
The picking of the thread is done here in
x86_linux_nat_target::read_description:
...
/* GNU/Linux LWP ID's are process ID's. */
tid = inferior_ptid.lwp ();
if (tid == 0)
tid = inferior_ptid.pid (); /* Not a threaded program. */
...
To understand what this code does, let's investigate a scenario in which
inferior_ptid.lwp () != inferior_ptid.pid ().
Say we start exec jit-attach-pie, identified with pid x. The main thread
starts another thread that sleeps, and then the main thread waits for the
sleeping thread. So we have two threads, identified with LWP IDs x and x+1:
...
PID LWP CMD
x x ./jit-attach-pie
x x+1 ./jit-attach-pie
...
[ The thread with LWP x is known as the thread group leader. ]
When attaching to this exec using the pid, gdb does a stop_all_threads which
iterates over all the threads, first LWP x, and then LWP x+1.
So the state we arrive with at x86_linux_nat_target::read_description is:
...
(gdb) p inferior_ptid
$1 = {m_pid = x, m_lwp = x+1, m_tid = 0}
...
and consequently we probe 64/32-bitness from thread LWP x+1.
[ Note that this is different from when gdb doesn't attach but instead
launches the exec itself, in which case there's no stop_all_threads needed,
and the probed thread is LWP x. ]
According to aforementioned remark, a better choice would have been the main
thread, that is, LWP x.
This patch implement that choice, by simply doing:
...
tid = inferior_ptid.pid ();
...
The fact that gdb makes a per-process choice for 64/32-bitness is a problem in
itself: each thread can be in either 64 or 32 bit mode. That is a problem
that this patch doesn't fix.
Tested on x86_64-linux.
[1] https://lore.kernel.org/io-uring/\
CAHk-=wh0KoEZXPYMGkfkeVEerSCEF1AiCZSvz9TRrx=Kj74D+Q@mail.gmail.com/
Any comments?
Thanks,
- Tom
[gdb/tdep] Use pid to choose x86_64 process 64/32-bitness
gdb/ChangeLog:
2021-05-07 Tom de Vries <tdevries@suse.de>
PR tdep/27822
* x86-linux-nat.c (x86_linux_nat_target::read_description): Use
pid to determine if process is 64-bit or 32-bit.
---
gdb/x86-linux-nat.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/gdb/x86-linux-nat.c b/gdb/x86-linux-nat.c
index 85c7f0ddc94..adea1ad0092 100644
--- a/gdb/x86-linux-nat.c
+++ b/gdb/x86-linux-nat.c
@@ -113,10 +113,7 @@ x86_linux_nat_target::read_description ()
static uint64_t xcr0;
uint64_t xcr0_features_bits;
- /* GNU/Linux LWP ID's are process ID's. */
- tid = inferior_ptid.lwp ();
- if (tid == 0)
- tid = inferior_ptid.pid (); /* Not a threaded program. */
+ tid = inferior_ptid.pid ();
#ifdef __x86_64__
{
next reply other threads:[~2021-05-07 8:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-07 8:44 Tom de Vries [this message]
2021-05-07 19:27 ` Simon Marchi via Gdb-patches
2021-05-07 20:06 ` Luis Machado via Gdb-patches
2021-05-19 16:32 ` Tom de Vries
2021-05-20 10:42 ` Alan Hayward via Gdb-patches
2021-05-20 16:07 ` Simon Marchi via Gdb-patches
2021-05-21 10:50 ` Alan Hayward via Gdb-patches
2021-05-22 8:32 ` Tom de Vries
2021-05-22 9:56 ` Tom de Vries
2021-05-23 1:27 ` Simon Marchi via Gdb-patches
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=20210507084402.GA14817@delia \
--to=tdevries@suse.de \
--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