From: Pedro Alves <pedro@palves.net>
To: gdb-patches@sourceware.org
Subject: [PATCH] Delay checking whether /proc/pid/mem is writable (PR gdb/29907)
Date: Fri, 16 Dec 2022 12:30:59 +0000 [thread overview]
Message-ID: <20221216123059.2458221-1-pedro@palves.net> (raw)
As of 1bcb0708f229 ("gdb/linux-nat: Check whether /proc/pid/mem is
writable"), GDB checks if /proc/pid/mem is writable. This is done
early in GDB startup, in order to get a consistent warning, instead of
a warning that depends on whenever GDB writes to inferior memory.
PR gdb/29907 points out that some build systems (like QEMU's,
apparently) may call 'gdb --version' to check GDB's presence & its
version on the system, and that Gentoo's build process has sandboxing
which blocks the /proc/pid/mem access and thus GDB warns, which
results in build fails.
To help with that, this patch delays the /proc/pid/mem check until we
start or attach to an inferior. Ends up potentially emiting a warning
close where we already emit other ptrace- and /proc- related warnings,
which just Feels Right.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29907
Change-Id: I5537653ecfbbe76a04ab035e40e59d09b4980763
---
gdb/linux-nat.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
index 1d207c4e31d..57444671c48 100644
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -372,6 +372,7 @@ linux_init_ptrace_procfs (pid_t pid, int attached)
linux_enable_event_reporting (pid, options);
linux_ptrace_init_warnings ();
linux_proc_init_warnings ();
+ proc_mem_file_is_writable ();
}
linux_nat_target::~linux_nat_target ()
@@ -3955,7 +3956,11 @@ linux_proc_xfer_memory_partial (int pid, gdb_byte *readbuf,
return true if so. It wasn't writable before Linux 2.6.39, but
there's no way to know whether the feature was backported to older
kernels. So we check to see if it works. The result is cached,
- and this is garanteed to be called once early at startup. */
+ and this is garanteed to be called once early during inferior
+ startup, so that any warning is print out consistently between GDB
+ invocations. Note we don't call it during GDB startup instead
+ though, because then we might warn with e.g. just "gdb --version"
+ on sandboxed systems. See PR gdb/29907. */
static bool
proc_mem_file_is_writable ()
@@ -4490,8 +4495,6 @@ Enables printf debugging output."),
sigemptyset (&blocked_mask);
lwp_lwpid_htab_create ();
-
- proc_mem_file_is_writable ();
}
\f
base-commit: 429f0cd1396203204754141681b1bc65bd3f5259
--
2.36.0
next reply other threads:[~2022-12-16 12:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 12:30 Pedro Alves [this message]
2022-12-16 14:20 ` 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=20221216123059.2458221-1-pedro@palves.net \
--to=pedro@palves.net \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).