From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32532 invoked by alias); 13 Jan 2009 11:04:12 -0000 Received: (qmail 32515 invoked by uid 22791); 13 Jan 2009 11:04:12 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.157) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Jan 2009 11:03:31 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n0DB3RYx024632 ; Tue, 13 Jan 2009 12:03:27 +0100 (CET) Received: from mailserver.u-strasbg.fr (ms3.u-strasbg.fr [IPv6:2001:660:2402:d::12]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id n0DB3Rt7061559 ; Tue, 13 Jan 2009 12:03:27 +0100 (CET) (envelope-from muller@ics.u-strasbg.fr) Received: from d620muller (www-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id n0DB3QOY060944 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Tue, 13 Jan 2009 12:03:26 +0100 (CET) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "'Joel Brobecker'" Cc: References: <20090110090843.GB29274@adacore.com> <20090110165031.GB24850@ednor.casa.cgf.cx> <20090111041848.GQ24105@adacore.com> <20090111042411.GA8509@ednor.casa.cgf.cx> <20090111132129.GS24105@adacore.com> <20090111155801.GA18734@host0.dyn.jankratochvil.net> <20090111183625.GA10501@ednor.casa.cgf.cx> <003101c974b9$e05d4330$a117c990$@u-strasbg.fr> <20090113102321.GX24105@adacore.com> In-Reply-To: <20090113102321.GX24105@adacore.com> Subject: RE: win32-nat.c to windows-nat.c rename Date: Tue, 13 Jan 2009 11:04:00 -0000 Message-ID: <007201c9756e$90b6c800$b2245800$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: 2009-01/txt/msg00275.txt.bz2 This problem has been fixed by the last patch from=20 Christopher that changed the type of cygwin_load_start and cygwin_load_end variables from bfd_vma to CORE_ADDR type. Thanks, Christopher ! Pierre Muller Pascal language support maintainer for GDB > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Joel Brobecker > Envoy=E9=A0: Tuesday, January 13, 2009 11:23 AM > =C0=A0: Pierre Muller > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: win32-nat.c to windows-nat.c rename >=20 > > There is also a > > problem if trying to generate a mutibuild on cygwin on a 32 bit > > machine with --enable-64-bit-bfd: >=20 > Is that something new? Apart from moving some of the code to a > different > file, I don't think I changed the actual code... >=20 > I'm wondering if I'm looking at the right version of the code. > For instance, it reports errors on the following two lines: >=20 > cygwin_load_start =3D (CORE_ADDR) (uintptr_t) ((char *) load_addr + > 0x1000); > cygwin_load_end =3D cygwin_load_start + bfd_section_size (abfd, text); >=20 > > ../../purecvs/gdb/windows-nat.c:654: warning: cast from pointer to > integer > > of different size >=20 > load_addr is an LPVOID (which is a void *), so casting it to (char *) > should be OK, then to (uintptr_t) should also be OK, and then to > a CORE_ADDR, it's an integer to integer conversion, that should be > OK too, no? >=20 > Do you see where the problem is? I'll see if I can reproduce > without cygwin... >=20 > -- > Joel