From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9688 invoked by alias); 20 Sep 2004 21:48:11 -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 9655 invoked from network); 20 Sep 2004 21:48:08 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 20 Sep 2004 21:48:08 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id i8KLm6J3022818; Mon, 20 Sep 2004 23:48:06 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id i8KLlNjZ041682; Mon, 20 Sep 2004 23:47:23 +0200 (CEST) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id i8KLlNd6041679; Mon, 20 Sep 2004 23:47:23 +0200 (CEST) Date: Mon, 20 Sep 2004 21:48:00 -0000 Message-Id: <200409202147.i8KLlNd6041679@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: cagney@gnu.org CC: gdb-patches@sources.redhat.com In-reply-to: <414F30D1.7080706@gnu.org> (message from Andrew Cagney on Mon, 20 Sep 2004 15:34:41 -0400) 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> X-SW-Source: 2004-09/txt/msg00328.txt.bz2 Date: Mon, 20 Sep 2004 15:34:41 -0400 From: Andrew Cagney > This is another step in the direction of eliminating the need for both > inf-ptrace.c and infptrace.c. It eliminates the calls to call_ptrace > and ptrace_wait. > > Andrew has recently suggested that we'd want debugging support for the > ptrace(2) interface, which could be implemented by using call_ptrace() > unconditionally. Having, again, spent some time debugging GNU/Linux threads, I'm pretty much certain of this. > 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. 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. Mark