From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12975 invoked by alias); 31 Oct 2007 18:42:49 -0000 Received: (qmail 12964 invoked by uid 22791); 31 Oct 2007 18:42:49 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 31 Oct 2007 18:42:46 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 83D6098348; Wed, 31 Oct 2007 18:42:44 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 10386981F1; Wed, 31 Oct 2007 18:42:44 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1InIWW-0004hG-IY; Wed, 31 Oct 2007 14:42:40 -0400 Date: Wed, 31 Oct 2007 19:12:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: dwarf2-frame.c read_reg problems, again ... Message-ID: <20071031184240.GA18037@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org References: <20071031021821.GB30157@caradoc.them.org> <200710311837.l9VIb3RY010625@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710311837.l9VIb3RY010625@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes 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-10/txt/msg00869.txt.bz2 On Wed, Oct 31, 2007 at 07:37:03PM +0100, Ulrich Weigand wrote: > So I don't mind making them unsigned again. How would that work > with the XML definitions? Do you have to add an explicit type > attribute everywhere? That's right. The default is "int", which is signed. When I was designing the format I thought up a pile of clever ways to make the format easier to write and more concise, like repeating register sets. Of course, they also make it harder to parse and more complicated to document. So I haven't implemented any of them :-) > I'd say targets like that should be able to define a proper conversion to > builtin_type_void_data_ptr via convert_register or value_from_register > for that specific register. > > Alternatively, if builtin_type_void_data_ptr is in fact the wrong > type to describe a CFA on some weird platform, we could allow the > gdbarch to define the type to be used for this. That's an interesting idea... I don't have a helpful opinion about this particular case, I'm afraid. I just don't want to break whatever Michael was working with, or MIPS again (which requires sign extension here). -- Daniel Jacobowitz CodeSourcery