From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10319 invoked by alias); 5 May 2006 16:30:01 -0000 Received: (qmail 10309 invoked by uid 22791); 5 May 2006 16:30:01 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 05 May 2006 16:29:59 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Fc3Bj-0008GJ-Ug; Fri, 05 May 2006 12:29:56 -0400 Date: Fri, 05 May 2006 16:30:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: pgilliam@us.ibm.com, gdb-patches@sources.redhat.com Subject: Re: [patch] Can't build ppc32 GDB Message-ID: <20060505162955.GB31029@nevyn.them.org> Mail-Followup-To: Mark Kettenis , pgilliam@us.ibm.com, gdb-patches@sources.redhat.com References: <1145924338.18934.45.camel@dufur.beaverton.ibm.com> <1145924593.18934.48.camel@dufur.beaverton.ibm.com> <200604251938.k3PJc9dl014571@elgar.sibelius.xs4all.nl> <1146699224.16180.4.camel@dufur.beaverton.ibm.com> <25493.192.87.1.22.1146726734.squirrel@webmail.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25493.192.87.1.22.1146726734.squirrel@webmail.xs4all.nl> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00065.txt.bz2 On Thu, May 04, 2006 at 09:12:14AM +0200, Mark Kettenis wrote: > This is where the new ISO C99 types come in handy. Instead of > casting to CORE_ADDR, try casting to uintptr_t. Can we rely on on GNU/Linux? I know we can't in general. Conveniently, I have a patch on one of my pending branches that provides a gdb_stdint.h. But for this case there's an easier solution, which IIRC is roughly what Paul did: I can pretty much promise you that sizeof (long) == sizeof (void *) on any GNU/Linux system. So either I can merge gdb_stdint.h and we can start using that, which might be a nice idea in general, or for now I think "long" is fine. -- Daniel Jacobowitz CodeSourcery