old-cross-binutils/gdb/ptrace.m4

105 lines
3.5 KiB
Text
Raw Normal View History

dnl Copyright (C) 2012-2016 Free Software Foundation, Inc.
dnl
dnl This file is part of GDB.
dnl
dnl This program is free software; you can redistribute it and/or modify
dnl it under the terms of the GNU General Public License as published by
dnl the Free Software Foundation; either version 3 of the License, or
dnl (at your option) any later version.
dnl
dnl This program is distributed in the hope that it will be useful,
dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
dnl GNU General Public License for more details.
dnl
dnl You should have received a copy of the GNU General Public License
dnl along with this program. If not, see <http://www.gnu.org/licenses/>.
dnl Check the return and argument types of ptrace.
AC_DEFUN([GDB_AC_PTRACE],
[
AC_CHECK_HEADERS([sys/ptrace.h ptrace.h])
C++: handle glibc's ptrace(enum __ptrace_request, ...) 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-24 13:57:20 +00:00
# Needs to be tested in C++ mode, to detect whether we need to cast
# the first argument to enum __ptrace_request.
if test "$enable_build_with_cxx" = "yes"; then
AC_LANG_PUSH([C++])
fi
gdb_ptrace_headers='
#include <sys/types.h>
#if HAVE_SYS_PTRACE_H
# include <sys/ptrace.h>
#endif
#if HAVE_UNISTD_H
# include <unistd.h>
#endif
'
# There is no point in checking if we don't have a prototype.
AC_CHECK_DECLS(ptrace, [], [
: ${gdb_cv_func_ptrace_ret='int'}
: ${gdb_cv_func_ptrace_args='int,int,long,long'}
], $gdb_ptrace_headers)
# Check return type. Varargs (used on GNU/Linux) conflict with the
# empty argument list, so check for that explicitly.
AC_CACHE_CHECK([return type of ptrace], gdb_cv_func_ptrace_ret,
AC_TRY_COMPILE($gdb_ptrace_headers,
[extern long ptrace (enum __ptrace_request, ...);],
gdb_cv_func_ptrace_ret='long',
AC_TRY_COMPILE($gdb_ptrace_headers,
[extern int ptrace ();],
gdb_cv_func_ptrace_ret='int',
gdb_cv_func_ptrace_ret='long')))
AC_DEFINE_UNQUOTED(PTRACE_TYPE_RET, $gdb_cv_func_ptrace_ret,
[Define as the return type of ptrace.])
# Check argument types.
AC_CACHE_CHECK([types of arguments for ptrace], gdb_cv_func_ptrace_args, [
AC_TRY_COMPILE($gdb_ptrace_headers,
[extern long ptrace (enum __ptrace_request, ...);],
C++: handle glibc's ptrace(enum __ptrace_request, ...) 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-24 13:57:20 +00:00
[gdb_cv_func_ptrace_args='enum __ptrace_request,int,long,long'],[
for gdb_arg1 in 'int' 'long'; do
for gdb_arg2 in 'pid_t' 'int' 'long'; do
for gdb_arg3 in 'int *' 'caddr_t' 'int' 'long' 'void *'; do
for gdb_arg4 in 'int' 'long' 'void *'; do
AC_TRY_COMPILE($gdb_ptrace_headers, [
extern $gdb_cv_func_ptrace_ret
ptrace ($gdb_arg1, $gdb_arg2, $gdb_arg3, $gdb_arg4);
], [gdb_cv_func_ptrace_args="$gdb_arg1,$gdb_arg2,$gdb_arg3,$gdb_arg4";
break 4;])
for gdb_arg5 in 'int *' 'int' 'long'; do
AC_TRY_COMPILE($gdb_ptrace_headers, [
extern $gdb_cv_func_ptrace_ret
ptrace ($gdb_arg1, $gdb_arg2, $gdb_arg3, $gdb_arg4, $gdb_arg5);
], [
gdb_cv_func_ptrace_args="$gdb_arg1,$gdb_arg2,$gdb_arg3,$gdb_arg4,$gdb_arg5";
break 5;])
done
done
done
done
done
# Provide a safe default value.
: ${gdb_cv_func_ptrace_args='int,int,long,long'}
])])
ac_save_IFS=$IFS; IFS=','
set dummy `echo "$gdb_cv_func_ptrace_args" | sed 's/\*/\*/g'`
IFS=$ac_save_IFS
shift
C++: handle glibc's ptrace(enum __ptrace_request, ...) 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-24 13:57:20 +00:00
AC_DEFINE_UNQUOTED(PTRACE_TYPE_ARG1, $[1],
[Define to the type of arg 1 for ptrace.])
AC_DEFINE_UNQUOTED(PTRACE_TYPE_ARG3, $[3],
[Define to the type of arg 3 for ptrace.])
AC_DEFINE_UNQUOTED(PTRACE_TYPE_ARG4, $[4],
[Define to the type of arg 4 for ptrace.])
if test -n "$[5]"; then
AC_DEFINE_UNQUOTED(PTRACE_TYPE_ARG5, $[5],
[Define to the type of arg 5 for ptrace.])
fi
C++: handle glibc's ptrace(enum __ptrace_request, ...) 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-24 13:57:20 +00:00
if test "$enable_build_with_cxx" = "yes"; then
AC_LANG_POP([C++])
fi
])