From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20715 invoked by alias); 21 Sep 2004 13:09:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20367 invoked from network); 21 Sep 2004 13:09:50 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 21 Sep 2004 13:09:50 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8LD9i3Y014534 for ; Tue, 21 Sep 2004 09:09:49 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8LD9ir04495; Tue, 21 Sep 2004 09:09:44 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E672B28D2; Tue, 21 Sep 2004 09:07:28 -0400 (EDT) Message-ID: <41502790.1080100@gnu.org> Date: Tue, 21 Sep 2004 13:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/RFC] Replace call_ptrace and ptrace_wait in inf-ptrace.c References: <200409201913.i8KJDosi035323@elgar.sibelius.xs4all.nl> <414F30D1.7080706@gnu.org> <200409202147.i8KLlNd6041679@elgar.sibelius.xs4all.nl> In-Reply-To: <200409202147.i8KLlNd6041679@elgar.sibelius.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00338.txt.bz2 > > That, however, is a bad idea, since this makes it > > impossible for the compiler to properly typecheck the arguments to > > ptrace(). > > How so? > > The variety in ptrace(2) prototypes is pretty big. Arguments can be > integer or pointer types of various sizes (32-bit, 64-bit). We simply > cannot get that right for all supported operating systems. So we have > to guess. Being conservative, we use a long integer type, say > CORE_ADDR, for the n-th argument of call_ptrace(). Suppose that on an > LP64 platform we pass, by mistake, a pointer as the n-th argument of > ptrace, but that argument should really be an int. Because of the > intermediate call_ptrace() the compiler doesn't warn us about it. The > result is probably a mysterious bug. Either way we'll end up with casts: CORE_ADDR -> (void *) (void *) -> long etc, why not have methods that at least avoid the casts (or do it locally to GDB's ptrace code?). > If we'd used a macro instead, the compiler would have warned us. > > I've noticed that ptrace can sometimes be declared with a variable > number of arguments, but that just suggests there should be a > gdb_ptrace4() and gdb_ptrace5() with explicitly 4 and 5 arguments. > > Linux does variable number of arguments, although the underlying > system call isn't. I believe the 5-arg SunOS-compatible > PTRACE_READDATA on SPARC Linux simply doesn't work. > > We shouldn't need an explicit 5-arg ptrace. The fifth argument is > always zero in GDB. good news Andrew