aboutsummaryrefslogtreecommitdiff
path: root/gdb/ptrace.m4
AgeCommit message (Collapse)AuthorFilesLines
2020-10-25gdb: move ptrace.m4 to gdbsupportSimon Marchi1-90/+0
ptrace.m4, providing the GDB_AC_PTRACE autoconf macro, is used by gdb, gdbserver and gdbsupport. I think it would make sense to move it to gdbsupport. gdb/ChangeLog: * acinclude.m4: Update ptrace.m4 path. * ptrace.m4: Moved to gdbsupport. gdbserver/ChangeLog: * acinclude.m4: Update ptrace.m4 path. gdbsupport/ChangeLog: * Makefile.in: Re-generate. * acinclude.m4: Update ptrace.m4 path. * ptrace.m4: Move here. Change-Id: I849c149fd5dd8c3b2b0af38654fb353e3727871b
2020-03-20gdb: remove HAVE_DECL_PTRACESimon Marchi1-5/+1
I stumbled on this snippet in nat/gdb_ptrace.h: /* Some systems, in particular DEC OSF/1, Digital Unix, Compaq Tru64 or whatever it's called these days, don't provide a prototype for ptrace. Provide one to silence compiler warnings. */ #ifndef HAVE_DECL_PTRACE extern PTRACE_TYPE_RET ptrace(); #endif I believe this is unnecessary today and should be removed. First, the comment only mentions OSes we don't support (and to be honest, I had never even heard of). But most importantly, in C++, a declaration with empty parenthesis declares a function that accepts no arguments, unlike in C. So if this declaration was really used, GDB wouldn't build, since all ptrace call sites pass some arguments. Since we haven't heard anything about this causing some build failures since we have transitioned to C++, I conclude that it's not used. This patch removes it as well as the corresponding configure check. gdb/ChangeLog: * ptrace.m4: Don't check for ptrace declaration. * config.in: Re-generate. * configure: Re-generate. * nat/gdb_ptrace.h: Don't declare ptrace if HAVE_DECL_PTRACE is not defined. gdbserver/ChangeLog: * config.in: Re-generate. * configure: Re-generate. gdbsupport/ChangeLog: * config.in: Re-generate. * configure: Re-generate.
2020-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
This commit applies all changes made after running the gdb/copyright.py script. Note that one file was flagged by the script, due to an invalid copyright header (gdb/unittests/basic_string_view/element_access/char/empty.cc). As the file was copied from GCC's libstdc++-v3 testsuite, this commit leaves this file untouched for the time being; a patch to fix the header was sent to gcc-patches first. gdb/ChangeLog: Update copyright year range in all GDB files.
2018-01-02Update copyright year range in all GDB filesJoel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files
2017-01-01update copyright year range in GDB filesJoel Brobecker1-1/+1
This applies the second part of GDB's End of Year Procedure, which updates the copyright year range in all of GDB's files. gdb/ChangeLog: Update copyright year range in all GDB files.
2016-04-18Fix PR gdb/19250: ptrace prototype is not detected properly in C++ modePedro Alves1-10/+0
The ptrace args/return types detection doesn't work properly in C++ mode, on non-GNU/Linux hosts. For example, on gcc70 (NetBSD 5.1), where the prototype is: int ptrace(int, __pid_t, void*, int); configure misdetects it as: $ grep PTRACE_TYPE config.h #define PTRACE_TYPE_ARG1 int #define PTRACE_TYPE_ARG3 int * #define PTRACE_TYPE_ARG4 int /* #undef PTRACE_TYPE_ARG5 */ #define PTRACE_TYPE_RET int resulting in: ../../src/gdb/amd64bsd-nat.c: In function 'void amd64bsd_fetch_inferior_registers(target_ops*, regcache*, int)': ../../src/gdb/amd64bsd-nat.c:56: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../src/gdb/amd64bsd-nat.c: In function 'void amd64bsd_store_inferior_registers(target_ops*, regcache*, int)': ../../src/gdb/amd64bsd-nat.c:104: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../src/gdb/amd64bsd-nat.c:110: warning: dereferencing type-punned pointer will break strict-aliasing rules We could address this [1], however despite ptrace.m4's claim: # Needs to be tested in C++ mode, to detect whether we need to cast # the first argument to enum __ptrace_request. it appears that there's actually no need to test in C++ mode. Always running the ptrace tests in C mode works just the same on GNU/Linux. I remember experimenting with several different ways to handle the original issue back then, and maybe that was needed in some other attempt and then I didn't realize it ended up not really necessary. Confirmed that this fixes the NetBSD 5.1 C++ build, and confirmed that C and C++ builds on Fedora 23 are unaffected. [1] - https://sourceware.org/ml/gdb-patches/2016-04/msg00374.html gdb/ChangeLog: 2016-04-18 Pedro Alves <palves@redhat.com> * ptrace.m4 (GDB_AC_PTRACE): Don't run tests in C++ mode. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2016-04-18 Pedro Alves <palves@redhat.com> * configure: Regenerate.
2016-01-01GDB copyright headers update after running GDB's copyright.py script.Joel Brobecker1-1/+1
gdb/ChangeLog: Update year range in copyright notice of all files.
2015-07-24C++: handle glibc's ptrace(enum __ptrace_request, ...)Pedro Alves1-1/+13
Building in C++ mode issues ~40 warnings like this: ../../src/gdb/linux-nat.c: In function ‘int linux_handle_extended_wait(lwp_info*, int, int)’: ../../src/gdb/linux-nat.c:2016:51: warning: invalid conversion from ‘int’ to ‘__ptrace_request’ [-fpermissive] ptrace (PTRACE_GETEVENTMSG, pid, 0, &new_pid); The issue is that in glibc, ptrace's first parameter is an enum. That's not a problem if we pick the PTRACE_XXX requests from sys/ptrace.h, as those will be values of the corresponding enum. However, we have fallback definitions for PTRACE_XXX symbols when the system headers miss them (such as PTRACE_GETEVENTMSG above), and those are plain integer constants. E.g., nat/linux-ptrace.h: #define PTRACE_GETEVENTMSG 0x4201 One idea would be to fix this by defining those fallbacks like: -#define PTRACE_GETEVENTMSG 0x4201 +#define PTRACE_GETEVENTMSG ((enum __ptrace_request) 0x4201) However, while glibc's ptrace uses enum __ptrace_request for first parameter: extern long int ptrace (enum __ptrace_request __request, ...) __THROW; other libc's, like e.g., Android's bionic do not -- in that case, the first parameter is int: long ptrace(int request, pid_t pid, void * addr, void * data); So the fix I came up is to make configure/ptrace.m4 also detect the type of the ptrace's first parameter and defin PTRACE_TYPE_ARG1, as already does the for parameters 3-4, and then simply wrap ptrace with a macro that casts the first argument to the detected type. (I'm leaving adding a nicer wrapper for when we drop building in C). While this adds the wrapper, GNU/Linux files won't use it until the next patch, which makes all native GNU/Linux files include gdb_ptrace.h. gdb/ChangeLog: 2015-07-24 Pedro Alves <palves@redhat.com> * ptrace.m4 (ptrace tests): Test in C++ mode. Try with 'enum __ptrace_request as first parameter type instead of int. (PTRACE_TYPE_ARG1): Define. * nat/gdb_ptrace.h [!PTRACE_TYPE_ARG5] (ptrace): Define as wrapper that casts first argument to PTRACE_TYPE_ARG1. * config.in: Regenerate. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2015-07-24 Pedro Alves <palves@redhat.com> * config.in: Regenerate. * configure: Regenerate.
2015-07-24make gdbserver use the same ptrace autoconf checks as gdbPedro Alves1-0/+92
This factors the ptrace checks out of gdb's configure.ac to a new ptrace.m4 file, and then makes gdbserver's configure.ac source it too. gdb/ChangeLog: 2015-07-24 Pedro Alves <palves@redhat.com> * acinclude.m4: Include ptrace.m4. * configure.ac: Call GDB_AC_PTRACE and move ptrace checks ... * ptrace.m4: ... to this new file. gdb/gdbserver/ChangeLog: 2015-07-24 Pedro Alves <palves@redhat.com> * acinclude.m4: Include ../ptrace.m4. * configure.ac: Call GDB_AC_PTRACE. * config.in, configure: Regenerate.