This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 2/5] New target port: Andes 'nds32'. (opcode)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Kuan-Lin Chen <kuanlinchentw at gmail dot com>
- Cc: <binutils at sourceware dot org>
- Date: Fri, 12 Jul 2013 16:56:36 +0000
- Subject: Re: [PATCH 2/5] New target port: Andes 'nds32'. (opcode)
- References: <CAJr6u0i7FwrYW9V7KB93UvOibTQQb5pZ6ZgNB1jVFvhc8mBJwg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1307091628540 dot 23421 at digraph dot polyomino dot org dot uk> <CAJr6u0jEYRq=0W06TsmpOgkSwzfvWE4bZg3H9Sp_AezXbOuwsg at mail dot gmail dot com>
On Fri, 12 Jul 2013, Kuan-Lin Chen wrote:
> 2013/7/10 Joseph S. Myers <firstname.lastname@example.org>:
> > Where is the source code for this patch? That is, the CGEN CPU
> > description (for addition to the cpu/ directory). Almost all this patch
> > appears to be generated files (which aren't needed in the diff; you just
> > need to give instructions for the person committing the patch to generate
> > them with CGEN).
> Because we modified some general parts of CGEN, I did not send the source
> code in this patch. The modification for two reason:
> 1. Add instruction print handler to disassemble more information for
> 2. In our target design, there are big and little endian for data but always big
> endian for instruction. In original CGEN, it does not support
> different data
> and instruction endian, so we modified it.
> We plan to write this part (opcode/) by ourselves not generating by
> CGEN in the feature.
> So, do I have to send all the modification of CGEN?
If a binutils port using CGEN is to be checked in, the CGEN CPU
description must be checked in, and it must work with the current mainline
version of CGEN in the src repository. CGEN-generated code must never be
checked in without all the sources required to regenerate it also being
checked in. In the past we've had to replace old binutils release
tarballs because they accidentally didn't contain the source code to some
of the CGEN CPU descriptions (in a directory that hadn't been included in
So, we simply can't consider this port for GNU binutils at all as long as
it involves a CGEN CPU description for which the source isn't available or
doesn't work with the checked-in CGEN sources. Either replace everything
in the port that's generated with CGEN, or get your CGEN changes committed
then submit the binutils port with the CGEN CPU description included.
Joseph S. Myers