From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6831 invoked by alias); 18 Apr 2007 08:31:31 -0000 Received: (qmail 6821 invoked by uid 22791); 18 Apr 2007 08:31:30 -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, 18 Apr 2007 09:31:28 +0100 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 1He5ZM-0003dc-00; Wed, 18 Apr 2007 09:31:16 +0100 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1He5ZF-0004gM-00; Wed, 18 Apr 2007 09:31:09 +0100 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1He5ZF-0007qH-9p; Wed, 18 Apr 2007 09:31:09 +0100 Date: Wed, 18 Apr 2007 09:59:00 -0000 From: "Maciej W. Rozycki" To: Michael Snyder cc: Daniel Jacobowitz , Mark Kettenis , gdb-patches@sourceware.org, Nigel Stephens , "Maciej W. Rozycki" Subject: Re: mips-tdep.c: FP varargs fixes In-Reply-To: <1176842694.5381.22.camel@svmsnyderlnx.palmsource.com> Message-ID: References: <200703231449.l2NEnQSb031165@brahms.sibelius.xs4all.nl> <20070410154430.GG10890@caradoc.them.org> <1176842694.5381.22.camel@svmsnyderlnx.palmsource.com> 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-04/txt/msg00276.txt.bz2 On Tue, 17 Apr 2007, Michael Snyder wrote: > > Well, GCC is the definite reference in this case ... > > You would think so -- but GCC has been known to get it wrong. > Historically, when gcc differs from the MIPS spec, we go with > the MIPS spec. Even if it means our tests fail. No question about it, but it makes sense only if accompanied with the respective bug report against GCC. Then some areas of the MIPS o32 ABI are obscure enough or plainly wrong (= useless as is -- see e.g. the R_MIPS_PC16 relocation), so that using a live piece of software instead is reasonably enough. And o64 does not even exist. ;-) Maciej