From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19390 invoked by alias); 30 Oct 2003 00:29:54 -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 19366 invoked from network); 30 Oct 2003 00:29:53 -0000 Received: from unknown (HELO mail.msmarts.com) (66.127.92.140) by sources.redhat.com with SMTP; 30 Oct 2003 00:29:53 -0000 Received: from lisa.msmarts.com (192.168.1.199 [192.168.1.199]) by mail.msmarts.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RYQ4KXN9; Wed, 29 Oct 2003 16:26:04 -0800 From: Ralph Escherich To: "Frank Ch. Eigler" Subject: Re: binutils porting to new CPU Date: Thu, 30 Oct 2003 00:29:00 -0000 User-Agent: KMail/1.5.9.1i Cc: cgen@sources.redhat.com References: <20031029165027.GA30779@redhat.com> In-Reply-To: <20031029165027.GA30779@redhat.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200310291631.09486.esche@mobilesmartsinc.com> X-SW-Source: 2003-q4/txt/msg00018.txt.bz2 I tried building binutils-2.14 for the openrisc-elf target and get the following error message: openrisc-asm.c: In function `openrisc_cgen_assemble_insn': openrisc-asm.c:584: error: `CGEN_INSN_RELAX' undeclared (first use in this function) openrisc-asm.c:584: error: (Each undeclared identifier is reported only once openrisc-asm.c:584: error: for each function it appears in.) make[3]: *** [openrisc-asm.lo] Error 1 openrisc-asm.c was generated by cgen Any ideas?? Esche On Wednesday 29 October 2003 08:50, Frank Ch. Eigler wrote: > Hi - > > > [...] > > Do you have a more detailed API description of what is generated and > > how it should be used for porting the binutils? [...] > > There isn't a really good list, I'm afraid. None of those who have > built a complete port took the extra time to document all the steps > and nuances. It's all rather vernacular: start based on an existing > port, do a massive search & replace for a new port name, ask here when > you run into trouble. A simple port may go smoothly enough not to > need any help. > > > Also gas/cgen.c contains code for fixups and parsing. How does all > > this fit into the big picture of porting binutils to a new cpu target? > > It's a necessary detail. The fewer addressing modes your target > supports, > and the simpler the layout of the operands that parametrize any given > address, the simpler (to almost nonexistent) these functions can be. > > > How do fixups and frags ??? fit into the API? [...] > > They barely do. Some CGEN operand parsing functions plop fixups into > the assembler, for ultimate disposition as an assembly-time constant, > or emission as a link-time relocation. Frags are little > partially-filled-in byte strings that are concatenated ultimately > to form object code. All this is deep GAS/BFD magic, not really cgen > related. > > > - FChE -- Ralph Escherich 2900 Gordon Avenue Suite 203 Senior IC Design Engineer Santa Clara, CA 95051-0718 Phone: 408-328-9333 Fax: 408-735-1163 http://www.mobilesmartsinc.com