From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31279 invoked by alias); 23 May 2012 15:42:48 -0000 Received: (qmail 31256 invoked by uid 22791); 23 May 2012 15:42:46 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 May 2012 15:42:27 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id EFFE1290078; Wed, 23 May 2012 17:42:31 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xxrR2WSDYe0; Wed, 23 May 2012 17:42:31 +0200 (CEST) Received: from province.act-europe.fr (province.act-europe.fr [10.10.0.214]) by mel.act-europe.fr (Postfix) with ESMTP id DB076290015; Wed, 23 May 2012 17:42:31 +0200 (CEST) Received: by province.act-europe.fr (Postfix, from userid 560) id 17BE1164883; Wed, 23 May 2012 17:42:26 +0200 (CEST) Date: Wed, 23 May 2012 15:42:00 -0000 From: Jerome Guitton To: Doug Evans Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [RFC] setting the raw content of a register Message-ID: <20120523154226.GT51051@adacore.com> References: <1337697398-25866-1-git-send-email-guitton@adacore.com> <4FBBA8C8.4030909@redhat.com> <20120522152459.GQ51051@adacore.com> <4FBBBF75.4040605@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) 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-05/txt/msg00899.txt.bz2 Doug Evans (dje@google.com): > On Tue, May 22, 2012 at 9:31 AM, Pedro Alves wrote: > > On 05/22/2012 04:24 PM, Jerome Guitton wrote: > > > >> Pedro Alves (palves@redhat.com): > >> > >>> What about : > >>> > >>>   p $f14 = {double} {0xFFF0000000000050} > >> > >> I've been testing with a bareboard PPC, and this needs malloc; > > > > > > Hmm, looks like you're right.  I was almost certain there was a way > > to avoid the malloc if the cast/conversion is done to a type of > > the exact same size as the source array, but it's escaping me now > > how. > > IWBN to solve this without adding a new command, the problem is more > general than just assigning values to registers. I may want to use > the value in an expression, for example. I can have a look. Still, we will have the problem that I was mentioning for cross targets: we sometimes lose the sign of the NaN. e.g. when debugging a ppc-elf target from a x86-linux host, {double} {0xFFF0000000000050} probably evaluates to NaN(0x100000001) instead of -NaN(0x000000050). Same kind of issue for denorms. We may improve the precision of the evaluation here, but I fear that it will take some time to catch all the possible cases. A new command would give a work around to anyone hitting such a precision loss.