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

[Chen Gang S]

On 2/14/15 11:37, Chris Metcalf wrote:
> On 2/13/2015 10:08 PM, Chen Gang S wrote:
>> On 2/14/15 08:26, Peter Maydell wrote:
>>> On 13 February 2015 at 23:50, Chen Gang S <address@hidden> wrote:
>>>> On 2/13/15 05:15, Chen Gang S wrote:
>>>>> It almost likes a template for adding an architecture target.
>>>>>
>>>>> Signed-off-by: Chen Gang <address@hidden>
>>>>> ---
>>>>>   configure                             |   7 ++
>>>>>   default-configs/tilegx-linux-user.mak |   1 +
>>>>>   target-tile/Makefile.objs             |   1 +
>>>>>   target-tile/cpu-qom.h                 |  72 +++++++++++++++
>>>>>   target-tile/cpu.c                     | 159 
>>>>> ++++++++++++++++++++++++++++++++++
>>>>>   target-tile/cpu.h                     |  84 ++++++++++++++++++
>>>>>   target-tile/helper.h                  |   0
>>>>>   target-tile/translate.c               |  54 ++++++++++++
>>>>>   8 files changed, 378 insertions(+)
>>>>>   create mode 100644 default-configs/tilegx-linux-user.mak
>>>>>   create mode 100644 target-tile/Makefile.objs
>>>>>   create mode 100644 target-tile/cpu-qom.h
>>>>>   create mode 100644 target-tile/cpu.c
>>>>>   create mode 100644 target-tile/cpu.h
>>>>>   create mode 100644 target-tile/helper.h
>>>>>   create mode 100644 target-tile/translate.c
>>>>>
>>>>> diff --git a/configure b/configure
>>>>> index 7ba4bcb..ffb4d56 100755
>>>>> --- a/configure
>>>>> +++ b/configure
>>>>> @@ -5191,6 +5191,9 @@ case "$target_name" in
>>>>>     s390x)
>>>>>       gdb_xml_files="s390x-core64.xml s390-acr.xml s390-fpr.xml"
>>>>>     ;;
>>>>> +  tilegx)
>>>>> +    TARGET_ARCH=tile
>>>>> +  ;;
>>>> Oh, it needs to use "TARGET_ARCH=tilegx" instead of "TARGET_ARCH=tile",
>>>> or can not put "CONFIG_TILE_DIS=y" to config-all-disas.mak, below (when
>>>> I am adding "disas/tilegx.c", I meet it).
>>> You need to make up your mind about what your architecture
>>> is called: is it "tile" or "tilegx"? Be consistent...
>>>
>> Oh, after think of, for me, I shall follow the other architectures has
>> done (e.g. i386).
>>
>>   - Still use target-tile directory, since 'tile' is the architecture
>>     name.
>>
>>   - 'tilegx' is one kind of cpu of tile, so I need consider about it just
>>     like another architectures have done (e.g. i386).
> 
> I recommend pretty strongly that you use "tilegx" consistently for qemu.  
> There is enough commonality in the Linux arch code that I chose "tile" to 
> support both tilepro and tilegx.  But elsewhere, we use "tilegx" vs 
> "tilepro", for example in binutils and gcc.  I would argue "qemu" is much 
> more like binutils or gcc.  Also, note that while x86_64 can run i386 
> binaries, tilegx can not run tilepro binaries.
> 

OK, thanks, what you said sounds reasonable to me, I shall only use
tilegx consistently for qemu.


>>> You should only add this bit to configure in the patchset
>>> where you add a Tile disassembler.
>> Yeah, I shall add disassembler firstly, before generate tcg code:
>>
>>   - binutils tilegx disassembler is easy to be integrated into qemu.
>>
>>   - I shall reuse part of the tilegx disassembler code for generating tcg
>>     code.
>>
>>   - For me, dumping disassemble code in qemu is much helpful for testing.
>>
>> At present, I have integrated binutils tilegx disassembler into qemu, it
>> is passed building, and I shall give a test for it tonight. If no any
>> issues, I plan to send related patch too.
> 
> The license issue is tricky with qemu.  The tilegx support was only returned 
> to the community in release 2.22, and binutils has been GPL v3 since 2.18 or 
> so.  So you can't use that code.  On the other hand, there is disassembly 
> code in the kernel that we released under the kernel's GPL v2; see 
> arch/tile/kernel/tile-desc_64.c and the matching include file.  So maybe 
> there is enough there for you to use to implement the disassembly code.
> 
> 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. :-)
> 

After read through the related kernel code, I guess, it is enough for me
to use to implement the disassembly code.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed