From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNV9d-0000nc-Qr for qemu-devel@nongnu.org; Mon, 16 Feb 2015 18:32:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNV9X-0006Ma-71 for qemu-devel@nongnu.org; Mon, 16 Feb 2015 18:32:41 -0500 Received: from mail113-251.mail.alibaba.com ([205.204.113.251]:60222 helo=us-alimail-mta1.hst.scl.en.alidc.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNV9W-0006M4-P8 for qemu-devel@nongnu.org; Mon, 16 Feb 2015 18:32:35 -0500 Message-ID: <54E27FDF.70904@sunrus.com.cn> Date: Tue, 17 Feb 2015 07:40:15 +0800 From: Chen Gang S 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> <54E205F3.5050403@ezchip.com> In-Reply-To: <54E205F3.5050403@ezchip.com> Content-Type: text/plain; charset=utf-8 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: Chris Metcalf , Peter Maydell Cc: "walt@tilera.com" , Riku Voipio , qemu-devel , "rth@twiddle.net" On 2/16/15 23:00, Chris Metcalf wrote: > 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. > OK, thanks, so I can continue. :-) >> - 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. > OK, thanks. At present, I just skip them, if I really meet the related issue (I guess not), I shall notify to tile related members. >> 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. > OK, thanks. > The disassembly stuff in the kernel allows you to recognize instructions, extract > operands (registers and immediates), etc. > OK, thanks, I guess, you mean that we can still be DISASM_ONLY (if what I guess is incorrect, please let me know). > 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. > OK, thanks, I guess you mean we need consider about BFD_RELOC, and may reference glib implementation to get help (binutils implements BFD_RELOC with the almost simplest and fewest code, but we can not use them). And I shall also try "!__KERNEL__ && !__LIBC__" to see the result, then decide whether we use them or not (I guess we can skip them, just like kernel version disassembler has done). Thanks -- Chen Gang Open, share, and attitude like air, water, and life which God blessed