Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 1 Oct 2015 23:08:55 +0300 (MSK)
From: Alexander Monakov <>
To: "" <>
Subject: RE: [PATCH] Define and use the __ptrace_request enumeration
 type in ptrace.

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:

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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.