From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2336 invoked by alias); 9 Nov 2004 16:23:17 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2198 invoked from network); 9 Nov 2004 16:23:08 -0000 Received: from unknown (HELO mms1.broadcom.com) (63.70.210.58) by sourceware.org with SMTP; 9 Nov 2004 16:23:08 -0000 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Tue, 09 Nov 2004 08:22:58 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id IAA01255; Tue, 9 Nov 2004 08:23:01 -0800 (PST) Received: from xl-sj1-04.sj.broadcom.com (xl-sj1-04 [10.16.129.247]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id iA9GMrov026689; Tue, 9 Nov 2004 08:22:53 -0800 (PST) Received: (from cgd@localhost) by xl-sj1-04.sj.broadcom.com ( 8.11.6/8.9.3) id iA9GMrT25135; Tue, 9 Nov 2004 08:22:53 -0800 X-Authentication-Warning: xl-sj1-04.sj.broadcom.com: cgd set sender to cgd@broadcom.com using -f To: "Andrew Cagney" cc: "David Ung" , gdb-patches@sources.redhat.com, nigel@mips.com Subject: Re: MIPS32 / MIPS64 release 2 support in simulator References: <1099495559.2778.53.camel@stockwell.mips.com> <1099576389.2778.90.camel@stockwell.mips.com> <418FA243.4060507@gnu.org> <1099937194.2780.151.camel@stockwell.mips.com> <4190EC00.6070501@gnu.org> From: cgd@broadcom.com Date: Tue, 09 Nov 2004 16:23:00 -0000 In-Reply-To: <4190EC00.6070501@gnu.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-WSS-ID: 6D8E31680BK2267270-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00163.txt.bz2 At Tue, 09 Nov 2004 11:10:40 -0500, Andrew Cagney wrote: > David, this isn't a technical decision (if it were, Chris would be > right). The new changes, or more exactly the new instructions, go in > a new file clearly marked (C) FSF (and for that matter clearly stating > that it was contributed by MIPS Inc). As for the mark-up of the > existing instructions, that's mindnumming tedium. > > Sorry about this pedentary. I'm off to pester another lawyer. Andrew, Once the legal issues are resolved on your end, will be it be acceptable from your POV to merge them all into mips.igen? Or do you believe they should always be separate? (Why is this necessary now, when it wasn't necessary back when we contributed the original mips32/mips64 support?) chris