[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
