From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8592 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: RE: [PATCH] Define and use the __ptrace_request enumeration type in ptrace. Date: Thu, 1 Oct 2015 23:08:55 +0300 (MSK) Message-ID: References: <8B7D5EC97CB15C4DBFDCE766959C1607C6ABD1@hhmail02.hh.imgtec.org>,<20150921203126.GU17773@brightrain.aerifal.cx> <8B7D5EC97CB15C4DBFDCE766959C1607C6C43E@hhmail02.hh.imgtec.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1443730156 28583 80.91.229.3 (1 Oct 2015 20:09:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 20:09:16 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-8604-gllmg-musl=m.gmane.org@lists.openwall.com Thu Oct 01 22:09:15 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZhkA9-0000dl-Ui for gllmg-musl@m.gmane.org; Thu, 01 Oct 2015 22:09:10 +0200 Original-Received: (qmail 7665 invoked by uid 550); 1 Oct 2015 20:09:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7647 invoked from network); 1 Oct 2015 20:09:07 -0000 In-Reply-To: <8B7D5EC97CB15C4DBFDCE766959C1607C6C43E@hhmail02.hh.imgtec.org> User-Agent: Alpine 2.20 (LNX 67 2015-01-07) Xref: news.gmane.org gmane.linux.lib.musl.general:8592 Archived-At: 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 #define ptrace(arg1, ...) ptrace(_pcast(PTRACE_TRACEME, arg1), __VA_ARGS__) template T _pcast(T, V v) { return static_cast(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