From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32400 invoked by alias); 24 Sep 2004 22:46:05 -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 32383 invoked from network); 24 Sep 2004 22:46:03 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 24 Sep 2004 22:46:03 -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 i8OMk3XQ029814 for ; Fri, 24 Sep 2004 18:46:03 -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 i8OMjlr02632; Fri, 24 Sep 2004 18:45:49 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9455328D2; Fri, 24 Sep 2004 18:43:31 -0400 (EDT) Message-ID: <4154A313.6050601@gnu.org> Date: Fri, 24 Sep 2004 22:46: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> <41502790.1080100@gnu.org> <200409242237.i8OMbNSY001761@elgar.sibelius.xs4all.nl> In-Reply-To: <200409242237.i8OMbNSY001761@elgar.sibelius.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00427.txt.bz2 > 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. Right, no matter what a single function is, casing is required. > I've tried to come up with a function signature for > gdb_ptrace() that would work for all targets, and I failed. With two ptrace functions, one with void* (for host buffer) and one with CORE_ADDR (for target address), this problem would be solved. Andrew