From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24697 invoked by alias); 1 Feb 2002 20:39:50 -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 24495 invoked from network); 1 Feb 2002 20:39:30 -0000 Received: from unknown (HELO toenail.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 1 Feb 2002 20:39:30 -0000 Received: (from fche@localhost) by toenail.toronto.redhat.com (8.11.6/8.11.6) id g11KdNT05119; Fri, 1 Feb 2002 15:39:23 -0500 Date: Fri, 01 Feb 2002 12:39:00 -0000 From: "Frank Ch. Eigler" To: Andrew Cagney Cc: binutils@sources.redhat.com, cgen@sources.redhat.com Subject: Re: include/dis-asm.h patch for cgen disassemblers Message-ID: <20020201153923.D4226@redhat.com> References: <20020131162132.I19966@redhat.com> <3C59BD4A.9060900@cygnus.com> <20020131184230.A6166@redhat.com> <3C59DB61.3000106@cygnus.com> <20020131195734.D6166@redhat.com> <3C5A3694.7020502@cygnus.com> <20020201092827.H6166@redhat.com> <3C5AE910.4090009@cygnus.com> <20020201145627.A4226@redhat.com> <3C5AF9D1.8070607@cygnus.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="LKTjZJSUETSlgu2t" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3C5AF9D1.8070607@cygnus.com>; from ac131313@cygnus.com on Fri, Feb 01, 2002 at 03:25:53PM -0500 X-SW-Source: 2002-q1/txt/msg00044.txt.bz2 --LKTjZJSUETSlgu2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1528 Hi -=20 cagney wrote: > [...] > > Referring to BFD misses the point! The BFD library barely cares about > > individual instructions or instruction sets. [...] >=20 > BFD sets the scene for its clients - LD, GDB, ... It defines an=20 > architecture / machine relationship (abet slighly broken in parts) > and applications use that. Yes. > My understanding of CGEN/SID is that they turned their back on BFD and=20 > defined a new set of architecture / machine relationships. Your understanding is incorrect. > GDB certainly doesn't want to go down that path. No one is asking. If the "isas" field extension goes in, and you prefer future gdb ports to continue using only the informal disassemble_options string, that's your prerogative. > [...] > > I need a way of identifying the list of sets of instructions ("instruct= ion > > sets", get it?) valid in some current context (processor state, mode, > > environment, whatever). I think the term "isas" is better than "mode", > > which is in turn better than "environment", to refer to this. Are we > > down to a mere choice-of-terminology issue? >=20 > Where is the fire? > See above, there is, I think a more fundamental problem here. The=20 > definition of bfd-architecture and machine are being quietly changed. No. A concept that already broadly exists outside bfd is being formally identified in the opcodes disassemble_info structure. Nothing in bfd is changing, and given this thread, even this lack of change is happening exceedingly un-quietly. - FChE --LKTjZJSUETSlgu2t Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 232 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Wvz7VZbdDOm/ZT0RAiL6AJsErQoHGXR9jfCjSCVhoAJyZ5uGSQCfTTzz eyDQdDq4EXkZD4AFyyMNhho= =FReo -----END PGP SIGNATURE----- --LKTjZJSUETSlgu2t--