RE: [PATCH] Define and use the __ptrace_request enumeration type in ptrace.

[Alexander Monakov <amonakov@ispras.ru>]

On Mon, 21 Sep 2015, Vasileios Kalintiris wrote:
> Out of curiosity, what is the general implementation choice in this case in
> other C libraries? I'm asking because discovering GLIBC and handing it as a
> special case would be easy through the __GLIBC__ macro. However, musl doesn't
> provide any such macro (and other C libraries probably).

Such unfortunate exposure of __ptrace_request appears to be specific to glibc
and uclibc (which wants to mirror glibc interfaces in other ways also).  BSD
libcs and Android's Bionic libc have a plain 'int' there.

As a result, LLDB already had to workaround __ptrace_request on Android:
https://github.com/llvm-mirror/lldb/blob/303c5382c20618cd07944023b259d138fc07c822/include/lldb/Host/linux/Ptrace.h#L19

It would make sense to 'typedef int __ptrace_request' in LLDB under '#ifndef
__GLIBC__' instead of '#ifdef __ANDROID_NDK__'.

(likewise it makes sense to guard '#define PT_DETACH PTRACE_DETACH' with
'#ifndef PT_DETACH')

If a more fancy fix is desired, it is also possible to hide the variations in
the first argument type via a bit of preprocessor and C++ duct tape:

#include <sys/ptrace.h>

#define ptrace(arg1, ...) ptrace(_pcast(PTRACE_TRACEME, arg1), __VA_ARGS__)

template<class T, class V>
T _pcast(T, V v)
{
  return static_cast<T>(v);
}


The above would allow to eliminate explicit typecasts where LLDB uses ptrace.

Or alternatively if GNU features are acceptable, one can simply use
__typeof__(PTRACE_TRACEME) to retrieve the underlying type.

Alexander