From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22714 invoked by alias); 19 Dec 2007 16:07:30 -0000 Received: (qmail 22700 invoked by uid 22791); 19 Dec 2007 16:07:29 -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; Wed, 19 Dec 2007 16:07:24 +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 1J51S4-0003aB-00; Wed, 19 Dec 2007 16:07:20 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1J51Rx-0006Z1-00; Wed, 19 Dec 2007 16:07:13 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1J51Rx-0001ja-CD; Wed, 19 Dec 2007 16:07:13 +0000 Date: Wed, 19 Dec 2007 16:16: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: <20071219152826.GA30488@caradoc.them.org> Message-ID: References: <20071216184625.GA22905@caradoc.them.org> <20071219152826.GA30488@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/msg00320.txt.bz2 On Wed, 19 Dec 2007, Daniel Jacobowitz wrote: > What happens to an 8-bit unsigned char? How about an 8-bit signed > char? Hmm, you have made me wonder... Obviously 32-bit integer quantities are special -- they are always sign-extended so that 32-bit ALU operations may be used on them. There is this statement in the ABI document: "All integer parameters are promoted (that is, sign- or zero-extended to 64-bit integers and passed in a single register). Typically, no code is required for the promotion." This note about no code requirement may be misleading -- this may be true for the run time, because the use of "lb/lbu/lh/lhu" as appropriate would have had the effect of doing the correct extension when the value was fetched into a register originally, but here we are in a different position as it is GDB that is the caller. Let me dig through the document... Nothing relevant apparently found. But in practice it should not matter -- however you represent 8-bit and 16-bit quantities you cannot overflow into the 64-bit data space as with a flip of the bit #31 the upper 32 bits follow and when a result is written back to memory or is otherwise finally processed (like output in a textual form) it has to be masked to its data width again (obviously "sb/sh" do this implicitly). So I believe the change is correct as it is and the question is academic. Let me know if you think otherwise. > What ABI is that? I thought none of the ELF targets used n32 or n64, > but maybe SDE is an exception. N32, as documented in "MIPSpro N32 ABI Handbook" from SGI. I can chase a link if you cannot locate the PDF. The SDE target uses it as the default 64-bit ABI implied by the "-mips64" switch. Maciej