summaryrefslogtreecommitdiff
path: root/gdbserver/linux-low.cc
diff options
context:
space:
mode:
authorPedro Alves <pedro@palves.net>2021-04-28 23:05:15 +0100
committerPedro Alves <pedro@palves.net>2021-05-08 13:45:36 +0100
commit4655f8509fd44e6efabefa373650d9982ff37fd6 (patch)
tree06c9df0c5eb22692fde447475a1cef56851568e1 /gdbserver/linux-low.cc
parente2ea3a381a4a7c739419a8b76a2fd132f7c1f9b1 (diff)
downloadbinutils-gdb-4655f8509fd44e6efabefa373650d9982ff37fd6.tar.gz
Don't run personality syscall at configure time; don't check it at all
Currently, in order to tell whether support for disabling address space randomization on Linux is available, GDB checks if the personality syscall works, at configure time. I.e., it does a run test, instead of a compile/link test: AC_RUN_IFELSE([PERSONALITY_TEST], [have_personality=true], [have_personality=false], This is a bit bogus, because the machine the build is done on may not (and is when you consider distro gdbs) be the machine that eventually runs gdb. It would be better if this were a compile/link test instead, and then at runtime, GDB coped with the personality syscall failing. Actually, GDB already copes. One environment where this is problematic is building GDB in a Docker container -- by default, Docker runs the container with seccomp, with a profile that disables the personality syscall. You can tell Docker to use a less restricted seccomp profile, but I think we should just fix it in GDB. "man 2 personality" says: This system call first appeared in Linux 1.1.20 (and thus first in a stable kernel release with Linux 1.2.0); library support was added in glibc 2.3. ... ADDR_NO_RANDOMIZE (since Linux 2.6.12) With this flag set, disable address-space-layout randomization. glibc 2.3 was released in 2002. Linux 2.6.12 was released in 2005. The original patch that added the configure checks was submitted in 2008. The first version of the patch that was submitted to the list called personality from common code: https://sourceware.org/pipermail/gdb-patches/2008-June/058204.html and then was moved to Linux-specific code: https://sourceware.org/pipermail/gdb-patches/2008-June/058209.html Since HAVE_PERSONALITY is only checked in Linux code, and ADDR_NO_RANDOMIZE exists for over 15 years, I propose just completely removing the configure checks. If for some odd reason, some remotely modern system still needs a configure check, then we can revert this commit but drop the AC_RUN_IFELSE in favor of always doing the AC_LINK_IFELSE cross-compile fallback. gdb/ChangeLog: * linux-nat.c (linux_nat_target::supports_disable_randomization): Remove references to HAVE_PERSONALITY. * nat/linux-personality.c: Remove references to HAVE_PERSONALITY. (maybe_disable_address_space_randomization) (~maybe_disable_address_space_randomizatio): Remove references to HAVE_PERSONALITY. * config.in, configure: Regenerate. gdbserver/ChangeLog: * linux-low.cc: (linux_process_target::supports_disable_randomization): Remove reference to HAVE_PERSONALITY. * config.in, configure: Regenerate. gdbsupport/ChangeLog: * common.m4 (personality test): Remove.
Diffstat (limited to 'gdbserver/linux-low.cc')
-rw-r--r--gdbserver/linux-low.cc4
1 files changed, 0 insertions, 4 deletions
diff --git a/gdbserver/linux-low.cc b/gdbserver/linux-low.cc
index ca3d25943df..9debe894eeb 100644
--- a/gdbserver/linux-low.cc
+++ b/gdbserver/linux-low.cc
@@ -6224,11 +6224,7 @@ linux_process_target::core_of_thread (ptid_t ptid)
bool
linux_process_target::supports_disable_randomization ()
{
-#ifdef HAVE_PERSONALITY
return true;
-#else
- return false;
-#endif
}
bool