From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7405 invoked by alias); 21 Jan 2009 14:22:16 -0000 Received: (qmail 7383 invoked by uid 22791); 21 Jan 2009 14:22:14 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_20 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (212.99.106.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Jan 2009 14:22:10 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id F28B7290004; Wed, 21 Jan 2009 15:22:07 +0100 (CET) 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 zZEVsO8miyc7; Wed, 21 Jan 2009 15:22:07 +0100 (CET) Received: from [192.168.1.3] (83-152-230-174.rev.libertysurf.net [83.152.230.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 1E487290001; Wed, 21 Jan 2009 15:22:07 +0100 (CET) From: Eric Botcazou To: Mark Kettenis Subject: Re: DWARF register numbering discrepancy on SPARC between GCC and GDB Date: Wed, 21 Jan 2009 14:22:00 -0000 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: gcc@gcc.gnu.org, brobecker@adacore.com, gdb@sourceware.org References: <20090121110847.GU5709@adacore.com> <200901211237.n0LCb2wB017368@brahms.sibelius.xs4all.nl> In-Reply-To: <200901211237.n0LCb2wB017368@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901211522.19829.ebotcazou@adacore.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-01/txt/msg00142.txt.bz2 > Obviously the GCC folks broke backwards compatibility with themselves. > So unless we find evidence that contradicts the wiki page you cite, I > think GCC needs to be fixed. Yes, the SVR4 definition used to be masked by that of the sol2.h file on Solaris and is not anymore. But the SVR4 definition is the one used for the various BSD variants. > OpenBSD and Linux are fine; they use 32-63 to number f0-f31. Linux is fine, OpenBSD is not, at least in the FSF tree. -- Eric Botcazou