aboutsummaryrefslogtreecommitdiff
path: root/gdb/ptrace.m4
AgeCommit message (Collapse)AuthorFilesLines
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.