From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30444 invoked by alias); 26 Nov 2007 15:18:30 -0000 Received: (qmail 30436 invoked by uid 22791); 26 Nov 2007 15:18:29 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Nov 2007 15:18:22 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id lAQFIJFK182158 for ; Mon, 26 Nov 2007 15:18:19 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lAQFIIV42977916 for ; Mon, 26 Nov 2007 16:18:18 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lAQFIIxC012401 for ; Mon, 26 Nov 2007 16:18:18 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id lAQFIH3E012398; Mon, 26 Nov 2007 16:18:17 +0100 Message-Id: <200711261518.lAQFIH3E012398@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 26 Nov 2007 16:18:17 +0100 Subject: Re: [RFC/RFA] Allow cygwin native to compile with --enable-64-bit-bfd To: muller@ics.u-strasbg.fr (Pierre Muller) Date: Mon, 26 Nov 2007 15:18:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <000001c8300c$8446c370$8cd44a50$@u-strasbg.fr> from "Pierre Muller" at Nov 26, 2007 10:12:49 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00483.txt.bz2 Pierre Muller wrote: > I didn't find many double typecast in gdb directory: > grep "([a-zA-Z0-9 ]*) *([a-zA-Z0-9 ]*)" *nat* > only found one occurrence: > spu-linux-nat.c: return (ULONGEST) (unsigned long) res; > and this does not even seem to be a pointer<->integer cast... Your regexp is missing "_", so it actually cannot match the cases involving intptr_t. It's true that even so there is not a large number of precedents, but that is because the operation of casting between host pointers and CORE_ADDR is quite rare (and that is how it should be!): inf-ptrace.c: (PTRACE_TYPE_ARG3)(uintptr_t) inf-ptrace.c: (PTRACE_TYPE_ARG3)(uintptr_t)rounded_offset, inf-ptrace.c: (PTRACE_TYPE_ARG3)(uintptr_t)rounded_offset, inf-ptrace.c: (PTRACE_TYPE_ARG3)(uintptr_t)rounded_offset, inf-ptrace.c: buf[i] = ptrace (PT_READ_U, pid, (PTRACE_TYPE_ARG3)(uintptr_t)addr, 0); inf-ptrace.c: ptrace (PT_WRITE_U, pid, (PTRACE_TYPE_ARG3)(uintptr_t)addr, buf[i]); linux-thread-db.c: ? (CORE_ADDR) (intptr_t) notify.u.bptaddr linux-thread-db.c: : (CORE_ADDR) (uintptr_t) notify.u.bptaddr), linux-thread-db.c: ? (CORE_ADDR) (intptr_t) address linux-thread-db.c: : (CORE_ADDR) (uintptr_t) address); ppc-linux-nat.c: *addr_p = (CORE_ADDR) (uintptr_t) siginfo_p->si_addr; proc-service.c: return (psaddr_t) (intptr_t) addr; proc-service.c: return (psaddr_t) (uintptr_t) addr; spu-linux-nat.c: return (ULONGEST) (unsigned long) res; spu-linux-nat.c: *word = ptrace (PT_READ_I, tid, (PTRACE_TYPE_ARG3) (size_t) memaddr, 0); spu-linux-nat.c: ptrace (PT_WRITE_D, tid, (PTRACE_TYPE_ARG3) (size_t) memaddr, word); > Please remember that my C knowledge is mainly limited to > the gdb sources themselves... > so if I have a CORE_ADDR that could be 64 bit > and I want to cast it to a pointer, I should use > (LPVOID) (uintptr_t) core_addr > and if I have a win32 API pointer that I want to > convert to a CORE_ADDR, I should use > (CORE_ADDR) (uintptr_t) pointer_var. Basically, yes. Except that "LPVOID" is rather a Windows-ism, it is not actually defined anywhere else ... You should be using "void *", or preferably the actual target pointer type. > My patch contained two conversions of the first type and > four of the second type (all with the same memaddr variable) > are macros really useful? Maybe to avoid future > similar problems... I'd prefer to not have macros, but just an explicitly written intermediate cast. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com