From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5775 invoked by alias); 26 Nov 2007 09:12:33 -0000 Received: (qmail 5704 invoked by uid 22791); 26 Nov 2007 09:12:32 -0000 X-Spam-Check-By: sourceware.org Received: from ics.u-strasbg.fr (HELO ics.u-strasbg.fr) (130.79.112.250) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Nov 2007 09:12:24 +0000 Received: from ICSMULLER (laocoon.u-strasbg.fr [130.79.112.72]) by ics.u-strasbg.fr (Postfix) with ESMTP id 0FEB818701A for ; Mon, 26 Nov 2007 10:16:52 +0100 (CET) From: "Pierre Muller" To: References: <000001c82dad$e507e0b0$af17a210$@u-strasbg.fr> <20071124210708.GE4928@ednor.casa.cgf.cx> <20071124224727.GA13580@caradoc.them.org> <20071125173207.GA7689@ednor.casa.cgf.cx> <20071125190823.GA11606@caradoc.them.org> <20071125221238.GB10356@ednor.casa.cgf.cx> In-Reply-To: <20071125221238.GB10356@ednor.casa.cgf.cx> Subject: RE: [RFC/RFA] Allow cygwin native to compile with --enable-64-bit-bfd Date: Mon, 26 Nov 2007 09:12:00 -0000 Message-ID: <000001c8300c$8446c370$8cd44a50$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us 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/msg00480.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] On Behalf Of Christopher Faylor > Sent: Sunday, November 25, 2007 11:13 PM > To: gdb-patches@sourceware.org > Subject: Re: [RFC/RFA] Allow cygwin native to compile with --enable-64- > bit-bfd > > On Sun, Nov 25, 2007 at 02:08:23PM -0500, Daniel Jacobowitz wrote: > >On Sun, Nov 25, 2007 at 12:32:08PM -0500, Christopher Faylor wrote: > >> On Sat, Nov 24, 2007 at 05:47:27PM -0500, Daniel Jacobowitz wrote: > >> >On Sat, Nov 24, 2007 at 04:07:08PM -0500, Christopher Faylor wrote: > >> >> > if (!target_read_string > >> >> >- ((CORE_ADDR) current_event.u.DebugString.lpDebugStringData, > &s, 1024, > >> >> >0) > >> >> >+ ((CORE_ADDR) addr, &s, 1024, 0) > >> >> > >> >> How can coercing something to uintptr_t and then to CORE_ADDR > achieve > >> >> anything? How does the double coercion help? > >> > > >> >Just the warning. CORE_ADDR will be long long, > >> >current_event.u.DebugString.lpDebugStringData will apparently be a > pointer. > >> > >> And the warning is? > > > >Cast from pointer to integer of different size. Casts are the way > >we've handled it elsewhere in GDB, but I wouldn't complain about a > >wrapper; casting host pointers to CORE_ADDRs is an action we try to > >keep to a minimum anyway. > > I wouldn't mind a double cast either, if there is precedent for that. 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... 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. 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... If we go for macros, I have no idea how to name those. #define CORE_ADDR_TO_POINTER (LPVOID) (uintptr_t) and #define POINTER_TO_CORE_ADDR (CORE_ADDR) (uintptr_t) I don't know if more braces are needed or not... It's probably best to still use uintptr_t as Pedro was talking about trying to support win64, no? Pierre