From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25803 invoked by alias); 26 Jul 2002 03:32:48 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 25791 invoked from network); 26 Jul 2002 03:32:47 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 26 Jul 2002 03:32:47 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id UAA19929; Thu, 25 Jul 2002 20:32:41 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma019923; Thu, 25 Jul 02 20:32:27 -0700 Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id g6Q3WWj04943; Thu, 25 Jul 2002 20:32:32 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id UAA21543; Thu, 25 Jul 2002 20:32:32 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15680.49872.654846.745688@casey.transmeta.com> Date: Thu, 25 Jul 2002 20:32:00 -0000 To: Andrew Cagney Cc: gdb@sources.redhat.com, cgen@sources.redhat.com Subject: Re: why cgen/cpu and not cgen in gdb_5_2_1-2002-07-23-release In-Reply-To: <3D3EF6CB.5080300@ges.redhat.com> References: <200207241732.KAA00372@casey.transmeta.com> <3D3EF6CB.5080300@ges.redhat.com> X-SW-Source: 2002-q3/txt/msg00007.txt.bz2 Andrew Cagney writes: > > I just checked out gdb_5_2_1-2002-07-23-release from the cvs tree. > > > > Question: Why are the cgen cpu files there but not cgen? > > Same reason GDB doesn't include autoconf, automake, gettext, bison, and > many other tools used to create generated files. Not needed. I recognize this. But cgen isn't autoconf. gdb/configure.in isn't shipped with autoconf. I'm wondering if more changes are required or different rules are at play. That's all. Methinks apps shipping the .cpu files in src/cgen/cpu without cgen is fragile. How fragile I dunno, but it is suspect. Ergo my question. [N.B. I'm not suggesting not shipping .cpu files. Nor am I suggesting shipping the cgen *.scm files. I'm just questioning the current situation. As an example, one could move the .cpu files to a different dir.] If I upgrade to autoconf 2.15, or some such, I don't expect any fundamental change to gdb. If I grab a copy of cgen off the net, it'll come with the .cpu files. All of a sudden my gdb 5.2 is now supporting the foo and bar insns of the baz cpu (assuming one configures the tree with --enable-cgen-maint or some such). I suppose we could have two different cgen releases, one with .cpu files (*1), one without. [Or, for completeness' sake, cgen could be instructed to use the .cpu files that came with the app, rather than the ones that came with it, but that's clearly rather fragile.] (*1): There's also .opc files. I'm using ".cpu files" as a catch-all. [One can certainly argue .opc files should live in opcodes, but that's another discussion.] Also, maybe now's the time to add version numbers to .cpu files. That is also another discussion.