diff options
author | Pedro Alves <pedro@palves.net> | 2021-04-28 23:05:15 +0100 |
---|---|---|
committer | Pedro Alves <pedro@palves.net> | 2021-05-08 13:45:36 +0100 |
commit | 4655f8509fd44e6efabefa373650d9982ff37fd6 (patch) | |
tree | 06c9df0c5eb22692fde447475a1cef56851568e1 /gdbserver/linux-low.cc | |
parent | e2ea3a381a4a7c739419a8b76a2fd132f7c1f9b1 (diff) | |
download | gdb-4655f8509fd44e6efabefa373650d9982ff37fd6.zip gdb-4655f8509fd44e6efabefa373650d9982ff37fd6.tar.gz gdb-4655f8509fd44e6efabefa373650d9982ff37fd6.tar.bz2 |
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.cc | 4 |
1 files changed, 0 insertions, 4 deletions
diff --git a/gdbserver/linux-low.cc b/gdbserver/linux-low.cc index ca3d259..9debe89 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 |