From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12960 invoked by alias); 29 Nov 2012 21:52:56 -0000 Received: (qmail 12939 invoked by uid 22791); 29 Nov 2012 21:52:52 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Nov 2012 21:52:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id AC0D52E36F; Thu, 29 Nov 2012 16:52:46 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bdnwJsroY7DG; Thu, 29 Nov 2012 16:52:46 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 604652E29B; Thu, 29 Nov 2012 16:52:45 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 8F68AC0359; Thu, 29 Nov 2012 22:52:42 +0100 (CET) Date: Thu, 29 Nov 2012 21:52:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Marcus Shawcroft , "gdb-patches@sourceware.org" Subject: Re: [PATCH 1/5] AArch64 GDB and GDBSERVER Port V2 Message-ID: <20121129215242.GN3581@adacore.com> References: <50AD0303.5030100@arm.com> <87mwy18kb2.fsf@fleche.redhat.com> <50B75C86.3080909@arm.com> <87ip8o7789.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ip8o7789.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-11/txt/msg00904.txt.bz2 > According to gnulib, PRIx64 is not portable. It is simpler to just use > the existing gdb infrastructure here, but if you really want inttypes.h, > then you need to use the appropriate gnulib module or something like that. I think we had that discussion before... I'd really like to avoid using those macros, especially since we should have the available infrastructure to do so. -- Joel