From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29471 invoked by alias); 20 Dec 2007 17:07:53 -0000 Received: (qmail 29460 invoked by uid 22791); 20 Dec 2007 17:07:52 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Dec 2007 17:07:48 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1J5Os5-0006i9-00; Thu, 20 Dec 2007 17:07:45 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1J5Os2-0001dg-00; Thu, 20 Dec 2007 17:07:42 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1J5Os2-0002ZX-AJ; Thu, 20 Dec 2007 17:07:42 +0000 Date: Thu, 20 Dec 2007 17:18:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: gdb-patches@sourceware.org, David Ung , "Maciej W. Rozycki" Subject: Re: mips-tdep.c: Sign-extend pointers for n32 In-Reply-To: <20071220165805.GB17663@caradoc.them.org> Message-ID: References: <20071216184625.GA22905@caradoc.them.org> <20071219152826.GA30488@caradoc.them.org> <20071219161552.GA1280@caradoc.them.org> <20071220165805.GB17663@caradoc.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com 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-12/txt/msg00347.txt.bz2 On Thu, 20 Dec 2007, Daniel Jacobowitz wrote: > I think there's still a problem here, though it is somewhat endemic to > the argument passing routines: > > TYPE_CODE_ENUM, /* Enumeration type */ > TYPE_CODE_REF, /* C++ Reference types */ > TYPE_CODE_CHAR, /* *real* character type */ > TYPE_CODE_BOOL, > > And possibly TYPE_CODE_MEMBERPTR too... that's a signed offset, > probably 32-bit in the n32 case. Getting this right is a real > pain. Hmm, these are obviously C-style types and I would expect other languages to have their own specific ones (Ada, anyone?). As they map somehow to the integer types provided by the underlying architecture, wouldn't it be a good idea to actually record which of the plain CPU-specific types each of the language types corresponds to? This way the mapping would only be provided in a single place -- the language ABI for a given architecture -- and all the generic target-dependent and possibly target-independent code would not have to iterate over all the language types, which is obviously prone to errors and hard to fully cover in the test suite. Maciej