From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14420 invoked by alias); 15 Mar 2002 02:46:25 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14349 invoked from network); 15 Mar 2002 02:46:14 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 15 Mar 2002 02:46:14 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C676C3EA9; Thu, 14 Mar 2002 21:46:08 -0500 (EST) Message-ID: <3C916070.50007@cygnus.com> Date: Thu, 14 Mar 2002 18:46:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: cgd@broadcom.com Cc: gdb@sources.redhat.com Subject: Re: problem w/ igen, multiple -M models, and -G gen-multi-sim. References: Content-Type: multipart/mixed; boundary="------------060108010401020908090607" X-SW-Source: 2002-03/txt/msg00130.txt.bz2 This is a multi-part message in MIME format. --------------060108010401020908090607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1212 > what's happening is that make_gen_semantics_list() is calling > insn_list_insert() to insert the DMxC1_COP1Sb on to the semantics list > (OK), but insn_list_insert finds that all of the keys it cares about > are the same, thinks it's a duplicate of DMxC1_COP1Sa, and merges it > into DMxC1_COP1Sa (not so OK), and as a result no semantic function is > generated for DMxC1_COP1Sb. Sounds like another key is needed (I keep adding them :-). > I don't know what the right solution here is, but I figured others > might want to be aware of the problem and might have comments. > > Having talked w/ Andrew a bit about the future of the MIPS sim, it's > going to move away from using -M like this, and instead use multiple > igen runs to generate simulators for different machines. So, this > isn't something that I need a solution to. > > I just wanted people who might care in the future to have a reference > in the list archives. If a solution comes out of this, well, that'd > be fine by me, too. 8-) Turns out that such instructions need to be given unique field-names as they would otherwise generate functions with the same name. Just explot it. See attached. It works for your example. Andrew --------------060108010401020908090607 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 1486 2002-03-14 Andrew Cagney * gen.c (format_name_cmp): New function. (insn_list_insert): Use the instruction field name as an additional key. Different field names indicate different semantics. Index: gen.c =================================================================== RCS file: /cvs/src/src/sim/igen/gen.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 gen.c --- gen.c 1999/04/16 01:35:04 1.1.1.1 +++ gen.c 2002/03/15 02:41:39 @@ -308,7 +308,18 @@ } } - +/* Same as strcmp(). */ +static int +format_name_cmp (const char *l, const char *r) +{ + if (l == NULL && r == NULL) + return 0; + if (l != NULL && r == NULL) + return -1; + if (l == NULL && r != NULL) + return +1; + return strcmp (l, r); +} typedef enum { @@ -346,6 +357,18 @@ /* key#3 sort according to the non-constant fields of each instruction */ cmp = insn_field_cmp (insn->words, (*cur_insn_ptr)->insn->words); + if (cmp < 0) + break; + else if (cmp > 0) + continue; + + /* key#4 sort according to the format-name. If two apparently + identical instructions have unique format-names, then the + instructions are different. This is because the + format-name's use is overloaded, it not only indicates the + format name but also provides a unique semantic name for the + function. */ + cmp = format_name_cmp (insn->format_name, (*cur_insn_ptr)->insn->format_name); if (cmp < 0) break; else if (cmp > 0) --------------060108010401020908090607--