From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNNPN-00076Z-TO for qemu-devel@nongnu.org; Mon, 16 Feb 2015 10:16:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNNPK-0000IR-GE for qemu-devel@nongnu.org; Mon, 16 Feb 2015 10:16:25 -0500 Received: from mail-db3on0059.outbound.protection.outlook.com ([157.55.234.59]:54670 helo=emea01-db3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNNPK-0000I8-82 for qemu-devel@nongnu.org; Mon, 16 Feb 2015 10:16:22 -0500 Message-ID: <54E205F3.5050403@ezchip.com> Date: Mon, 16 Feb 2015 10:00:03 -0500 From: Chris Metcalf MIME-Version: 1.0 References: <54DD17BC.5040006@sunrus.com.cn> <54DD180B.3080004@sunrus.com.cn> <54DE8DCA.6030302@sunrus.com.cn> <54DEBC3E.4000805@sunrus.com.cn> <54DEC303.6030502@ezchip.com> <54DF6F90.60406@sunrus.com.cn> <54E1669F.9090402@sunrus.com.cn> <54E20265.9040606@sunrus.com.cn> In-Reply-To: <54E20265.9040606@sunrus.com.cn> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chen Gang S , Peter Maydell Cc: "walt@tilera.com" , Riku Voipio , qemu-devel , "rth@twiddle.net" On 2/16/2015 9:44 AM, Chen Gang S wrote: > Excuse me, after comparing the code details between kernel version > disassembler and binutils version disassembler, I am sure the kernel > version disassembler is the part of the binutils version disassembler: Yes, exactly. We used an unifdef tool and some reindenting to generate the kernel version from the same master that we used to generate the binutils version. We released the two under different licenses. I'm pretty comfortable that all of this is in the letter and spirit of copyright and license. So you can start with the kernel version and you will inherit the GPL v2 license of that code. > - kernel version decode_X1_fsm[1206] is older than binutils version > decode_X1_fsm[1266]. I'm pretty sure this represents the ld_tls family of instructions that are present in binutils. However, these are updated by the runtime loader, so you won't see them if you are disassembling live code anyway. If it for some reason this becomes an issue, I expect we could generate an appropriate update for the kernel version. > I guess, for qemu, we need !DISASM_ONLY, and may need BFD_RELOC, and may > need the latest decode_X1_fsm, and also may need !__KERNEL__ -- which > means we will use the full binutils version disassembler!! > > In current condition, I really don't know how to do next. Welcome any > ideas, and suggestions. Honestly, I'm not sure that that's true. Mostly you just need to be able to recognize instructions, I would think. I suspect it's worth pushing ahead with the kernel stuff as a base and see more precisely what you think is missing. I don't know the qemu requirements well enough to give an educated opinion. The disassembly stuff in the kernel allows you to recognize instructions, extract operands (registers and immediates), etc. There is also some code in glibc's sysdep/tile/dl-machine.h which implements the runtime loader relocation processing, under GPL v2.1; perhaps some of that would be relevant to what qemu does? Again, I'm not really sure. On 2/14/15 23:53, Chen Gang S wrote: >>> On 2/14/15 13:47, Peter Maydell wrote: >>>> On 14 February 2015 at 03:37, Chris Metcalf wrote: >>>>> I'm not sure whether Tilera can simply re-release the tilegx-specific stuff >>>>> from binutils as a separate tarball with GPL v2 licensing. Hopefully we can >>>>> avoid having to figure that out. :-) >>>> I believe it is theoretically possible (the usual FSF copyright arrangements >>>> involve the original authors giving the copyright to the FSF but being >>>> granted back a right to distribute their work under other licenses). >>>> However it is definitely a "check with your lawyers" kind of question >>>> and I entirely appreciate the desire to avoid having to go down that >>>> route :-) >>>> >>> For me, the main feature of kernel disassembly implementation is almost >>> the same as the feature of binutils disassembly implementation. And all >>> of related code are not quite much (only several thousand lines), >>> >>> So at present, I guess, we needn't consider more about the related >>> license. >>> >>> >>> Thanks >>> -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com