From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26870 invoked by alias); 24 Sep 2004 22:37: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 26615 invoked from network); 24 Sep 2004 22:37:34 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 24 Sep 2004 22:37:34 -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 i8OMbSPV020793; Sat, 25 Sep 2004 00:37:28 +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 i8OMbNfv001764; Sat, 25 Sep 2004 00:37: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 i8OMbNSY001761; Sat, 25 Sep 2004 00:37:23 +0200 (CEST) Date: Fri, 24 Sep 2004 22:37:00 -0000 Message-Id: <200409242237.i8OMbNSY001761@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: cagney@gnu.org CC: gdb-patches@sources.redhat.com In-reply-to: <41502790.1080100@gnu.org> (message from Andrew Cagney on Tue, 21 Sep 2004 09:07:28 -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> <200409202147.i8KLlNd6041679@elgar.sibelius.xs4all.nl> <41502790.1080100@gnu.org> X-SW-Source: 2004-09/txt/msg00424.txt.bz2 Date: Tue, 21 Sep 2004 09:07:28 -0400 From: Andrew Cagney I committed the patch: 2004-09-24 Mark Kettenis * inf-ptrace.c (inf_ptrace_kill_inferior): Call ptrace directly instead of call_ptrace. Call wait directly instead of ptrace_wait. (inf_ptrace_me): Call ptrace directly instead of call_ptrace. (inf_ptrace_wait): Inline ptrace_wait call. But this doesn't mean we shouldn't continue this discussion. It actually makes things easier for us whatever the outcome because now we can forget about replacing call_ptrace, and can just focus on ptrace(). Please read on. > 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?). The problem here is that the third argument of ptrace is used for two purposes: 1. For specifying memory addresses of objects in the debugger's address space (PT_GETREGS, PT_SETREGS, PT_IO). 2. For specifying memory addresses in the inferior. This gets especially complicated with 32x64 "native" cross-debugging and is further complicated by the fact that some systems use an integer type and other systems use a pointer type for this third arguments. I've tried to come up with a function signature for gdb_ptrace() that would work for all targets, and I failed. Mark