From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23899 invoked by alias); 29 Oct 2003 02:48:13 -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 23868 invoked from network); 29 Oct 2003 02:48:03 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 29 Oct 2003 02:48:03 -0000 Received: from tooth.toronto.redhat.com (tooth.toronto.redhat.com [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 6E9F680040E; Tue, 28 Oct 2003 21:48:03 -0500 (EST) Received: from tooth.toronto.redhat.com (IDENT:6PssY3A7/k1fC917af8UDsuk0C2O24Fj@localhost [127.0.0.1]) by tooth.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id h9T2m3j5010099; Tue, 28 Oct 2003 21:48:03 -0500 Received: (from fche@localhost) by tooth.toronto.redhat.com (8.12.8/8.12.8/Submit) id h9T2m2x4010096; Tue, 28 Oct 2003 21:48:02 -0500 Date: Wed, 29 Oct 2003 02:48:00 -0000 From: "Frank Ch. Eigler" To: Ralph Escherich Cc: cgen@sources.redhat.com Subject: Re: binutils porting to new CPU Message-ID: <20031029024802.GA9756@redhat.com> References: <200310281821.24902.esche@mobilesmartsinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310281821.24902.esche@mobilesmartsinc.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-q4/txt/msg00015.txt.bz2 Hi - > [...] > My research on the web shows, that for a complete port of the binutils > to a new cpu the follwing parts have to be modified/created: > [...] > include/opcodes/FOO.h - Port specific ISA encoding > opcodes/FOO-dis.c - Port specific disassembler routines > opcodes/FOO-opc.c - Port specific ISA encoding These are the only files generated by cgen for binutils, but you'll notice that these are the primary ones that contain the most complex aspects for supporting target processor. The others need to be built by hand. Of these, only the bfd/{*}-FOO.c file has given me particular headaches, having to represent object file relocations in a clunky way. (This part motivated Red Hat to build a reusable generic relocation engine for a particularly peculiar & reconfigurable target. This code has not been made public though AFAIK.) - FChE