qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minim


From: Chen Gang S
Subject: Re: [Qemu-devel] [PATCH 1/5] target-tile: Firstly add to qemu with minimized features
Date: Tue, 17 Feb 2015 07:40:15 +0800
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]