|
Message-ID: <alpine.LNX.2.20.1510012250220.16756@monopod.intra.ispras.ru> Date: Thu, 1 Oct 2015 23:08:55 +0300 (MSK) From: Alexander Monakov <amonakov@...ras.ru> To: "musl@...ts.openwall.com" <musl@...ts.openwall.com> 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: 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
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.