On 2/28/15 13:20, Chen Gang S wrote:
>>> diff --git a/target-tilegx/helper.h b/target-tilegx/helper.h
>>> >> new file mode 100644
>>> >> index 000..e69de29
>> >
>> > Is this empty file actually included from somewhere in this patch?
&
On 2/28/15 01:36, Andreas Färber wrote:
>> +static void tilegx_cpu_class_init(ObjectClass *oc, void *data)
>> > +{
>> > +DeviceClass *dc = DEVICE_CLASS(oc);
>> > +CPUClass *cc = CPU_CLASS(oc);
>> > +TilegxCPUClass *mcc = TILEGX_CPU_CLASS(oc);
>> > +
>> > +mcc->parent_realize = dc->r
Firstly, thank you very much for your patient work!
On 2/28/15 01:36, Andreas Färber wrote:
> Hi,
>
> "target-tilegx: Initial stub" or "...support"? No need to mention QEMU
> (spelling!) in a QEMU commit.
>
OK, thanks.
> Am 22.02.2015 um 14:33 sch
On 2/28/15 10:09, Chris Metcalf wrote:
> On 2/27/2015 9:10 PM, Chen Gang S wrote:
>> By the way, does Gx8000 mean 8000 core count?
>
> It's marketing, so it doesn't have to mean anything. The TILE-Gx 8036 is the
> 36-core part, the 8072 is the 72-core part,
On 2/28/15 05:49, Chris Metcalf wrote:
> On 2/27/2015 12:36 PM, Andreas Färber wrote:
>> "TILE-Gx" according to
>> http://www.tilera.com/products/?ezchip=585&spage=614 - please fix
>> wherever used in textual form.
>
> Yes, really only "tilegx" or "TILE-Gx" should be used. In type names I agree
On 02/28/2015 01:40 AM, Andreas Färber wrote:
> Am 22.02.2015 um 14:36 schrieb Chen Gang S:
>> Add tilegx architecture in "syscall_defs.h", all related features (ioctrl,
>> and stat) are based on Linux kernel tilegx 64-bit implementation.
>>
>> Signed-off
On 02/28/2015 02:24 AM, Andreas Färber wrote:
> Am 22.02.2015 um 14:37 schrieb Chen Gang S:
>> For tilegx, several syscall macros are not supported, so switch them to
>> avoid building break.
>>
>> Signed-off-by: Chen Gang
>>
On 2/27/15 11:01, Chris Metcalf wrote:
> On 2/25/2015 8:44 PM, Chen Gang S wrote:
>> On 02/26/2015 01:19 AM, Richard Henderson wrote:
>>> On 02/24/2015 05:40 PM, Chen Gang S wrote:
>>>>>> +static int gen_shl16insli(struct DisasContext *dc,
>>>>
On 02/26/2015 01:19 AM, Richard Henderson wrote:
> On 02/24/2015 05:40 PM, Chen Gang S wrote:
>>>> +static int gen_shl16insli(struct DisasContext *dc,
>>>> + unsigned char rdst, unsigned char rsrc, short
>>>> im16)
>>&
PM, Chen Gang S wrote:
>> +env->zero = 0;
>
> I replied elsewhere about the zero register.
>
OK, thanks.
>> +#define TILEGX_GEN_CHK_BEGIN(x) \
>> +if ((x) == TILEGX_R_ZERO) {
>> +#define TILEGX_GEN_CHK_END(x) \
>> +return 0; \
On 2/25/15 02:18, Chris Metcalf wrote:
> On 2/24/2015 12:25 PM, Chen Gang S wrote:
>> For me, if the raw integer is only used once, we needn't define a macro
>> for it (instead of, we can give a comment for it).
>
> The advantage of names even in this case is that you
On 2/25/15 00:46, Chris Metcalf wrote:
> On 2/24/2015 11:31 AM, Chen Gang S wrote:
>> - When dst is zero, in most cases, we can just skip the insn, but in
>> some cases, it may cause exception in user mode (e.g st zero r0).
>
> Be careful of skipping instructions
On 2/25/15 00:42, Richard Henderson wrote:
> On 02/24/2015 05:39 AM, Chen Gang S wrote:
>> After read through target-arm/translate-a64.c, I guess, the main reason
>> is: the zero register (r31) shares with the sp register (also r31).
>>
>> - So it uses cpu_reg(
On 2/24/15 22:21, Chris Metcalf wrote:
> On 2/24/2015 2:53 AM, Chen Gang S wrote:
>> typedef struct CPUTLState {
>> +uint64_t regs[TILEGX_R_COUNT]; /* Common used registers by outside */
>> +uint64_t zero; /* Zero register *
On 2/24/15 22:38, Peter Maydell wrote:
> On 24 February 2015 at 23:21, Chris Metcalf wrote:
>> On 2/24/2015 2:53 AM, Chen Gang S wrote:
>>>
>>> typedef struct CPUTLState {
>>> +uint64_t regs[TILEGX_R_COUNT]; /* Common used registers
On 2/24/15 15:53, Chen Gang S wrote:
[...]
> diff --git a/target-tilegx/translate.c b/target-tilegx/translate.c
> index 5131fa7..82c751e 100644
> --- a/target-tilegx/translate.c
> +++ b/target-tilegx/translate.c
> @@ -25,18 +25,880 @@
> #include "exec/cpu_ldst.h"
&g
Tilegx Qemu can decode bundle, disassemble code, and generate tcg code
for 1st TB block (__start). Then directly jump to __libc_start_main (2nd
TB block).
In __libc_start_main, tilegx qemu continues executing, and reach to the
indirectly jump statement, and jump to 3rd TB block correctly.
The rel
On 2/23/15 02:29, Richard Henderson wrote:
> On 02/22/2015 05:31 AM, Chen Gang S wrote:
>> Chen Gang (6):
>> target-tilegx: Firstly add to qemu with minimized features
>> linux-user: tilegx: Firstly add architecture related features
>> linux-user: tilegx: Add tar
On 2/23/15 06:32, Bastian Koppelmann wrote:
>
> On 02/22/2015 01:31 PM, Chen Gang S wrote:
>> Chen Gang (6):
>>target-tilegx: Firstly add to qemu with minimized features
>>linux-user: tilegx: Firstly add architecture related features
>>linux-user: tileg
For tilegx, several syscall macros are not supported, so switch them to
avoid building break.
Signed-off-by: Chen Gang
---
linux-user/syscall.c | 50 +-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux-user
Add main working flow feature and loading elf64 tilegx binary feature,
based on Linux kernel tilegx 64-bit implementation.
After this patch, qemu can successfully load elf64 tilegx binary for
linux-user, and the working flow reaches the first correct instruction
position "__start".
Signed-off-by:
Add tilegx architecture in "syscall_defs.h", all related features (ioctrl,
and stat) are based on Linux kernel tilegx 64-bit implementation.
Signed-off-by: Chen Gang
---
linux-user/syscall_defs.h | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff
They are for target features within qemu which independent from outside.
Signed-off-by: Chen Gang
---
linux-user/tilegx/target_cpu.h | 35 +++
linux-user/tilegx/target_signal.h | 28 ++
linux-user/tilegx/target_structs.h | 48 +
It almost likes a template for adding an architecture target.
Signed-off-by: Chen Gang
---
configure | 7 ++
default-configs/tilegx-linux-user.mak | 1 +
target-tilegx/Makefile.objs | 1 +
target-tilegx/cpu-qom.h | 72 +++
ta
After load elf64 tilegx binary for linux-user, the working flow reaches
1st correct instruction "__start". Next, we shall load all instructions
for qemu using.
This patch is based on Linux kernel tile architecture tilegx 64-bit
implementation, and also based on tilegx architecture ABI reference.
On 2/22/15 09:08, Chen Gang S wrote:
> On 2/22/15 08:25, Chris Metcalf wrote:
[...]
>> Similarly, if any pipeline takes an exception (a TLB fault from a memory op,
>> a GPV fault from an illegal mfspr, etc) then no pipeline completes its
>> action.
>>
>
> Oh,
On 2/22/15 08:25, Chris Metcalf wrote:
> On 2/21/2015 7:25 PM, Chen Gang S wrote:
>> On 2/22/15 00:33, Richard Henderson wrote:
>>> >On 02/21/2015 07:31 AM, Chen Gang S wrote:
>>>> >>
>>>> >> - We can still use the original pipes order: &q
On 2/22/15 00:33, Richard Henderson wrote:
> On 02/21/2015 07:31 AM, Chen Gang S wrote:
>>
>> - We can still use the original pipes order: "y0, y2, y1" and "x0, x1".
>
> I guess, sure, though I don't think that'll help as much as you imagine
ether
the execution is correct or not).
But I guess, I have to fix current issue firstly, before continue.
Thanks.
On 2/21/15 23:31, Chen Gang S wrote:
>
> Oh, we can not only assume y1 and x1 is the last execution in a bundle,
> e.g. in __libc_start_main:
>
>11330:
temporary variables, they also need to
consider about jump cases for tcg code (flush tcg temporary variables
after comparing and before jump).
Welcome any ideas, suggestions or completions.
Thanks.
On 2/21/15 15:16, Chen Gang S wrote:
> On 2/21/15 11:05, Chen Gang S wrote:
>> A
On 2/21/15 11:55, Chris Metcalf wrote:
> On 2/19/2015 7:07 PM, Chen Gang S wrote:
>> +#ifdef TARGET_NR_chown /* not on tilegx */
>
> I would omit all these comments. The same will be true for arm64,
> microblaze, or any other kernel architecture submitted after the tile
>
On 2/21/15 11:05, Chen Gang S wrote:
> At present finish decoding the first TB block: _start. Always let y1 and
> x1 pipe at the last which may content jump instructions.
>
> The related disassembly code is below which is the same as the objdump:
>
> y0: 500bfdb4 mo
At present finish decoding the first TB block: _start. Always let y1 and
x1 pipe at the last which may content jump instructions.
The related disassembly code is below which is the same as the objdump:
y0: 500bfdb4 move r52, r54
y2: 02080760 ld r1, r54
y1: 1c064000
They are based on Linux kernel tilegx architecture for 64 bit binary,
also based on tilegx ABI reference document.
Signed-off-by: Chen Gang
---
linux-user/tilegx/syscall.h| 80
linux-user/tilegx/syscall_nr.h | 278
linux-user/tilegx/term
For tilegx, several syscall macros are not supported, so switch them to
avoid building break.
Signed-off-by: Chen Gang
---
linux-user/syscall.c | 50 +-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux-user
Add main working flow feature and loading elf64 tilegx binary feature,
based on Linux kernel tilegx 64-bit implementation.
After this patch, qemu can successfully load elf64 tilegx binary for
linux-user, and the working flow reaches the first correct instruction
position "__start".
Signed-off-by:
They are for target features within qemu which independent from outside.
Signed-off-by: Chen Gang
---
linux-user/tilegx/target_cpu.h | 35 +++
linux-user/tilegx/target_signal.h | 28 ++
linux-user/tilegx/target_structs.h | 48 +
Add tilegx architecture in "syscall_defs.h", all related features (ioctrl,
and stat) are based on Linux kernel tilegx 64-bit implementation.
Signed-off-by: Chen Gang
---
linux-user/syscall_defs.h | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff
After load elf64 tilegx binary for linux-user, the working flow reaches
1st correct instruction "__start". Next, we shall load all instructions
for qemu using.
This patch is based on Linux kernel tile architecture tilegx 64-bit
implementation, and also based on tilegx architecture ABI reference.
It almost likes a template for adding an architecture target.
Signed-off-by: Chen Gang
---
configure | 7 ++
default-configs/tilegx-linux-user.mak | 1 +
target-tilegx/Makefile.objs | 1 +
target-tilegx/cpu-qom.h | 72 +++
ta
On 2/17/15 23:58, Richard Henderson wrote:
> On 02/16/2015 06:59 PM, Chen Gang S wrote:
>> I have the related documents, but I can not find pc register, and I
>> originally misunderstood lr can be treated as pc. After I know we can
>> not treat lr as pc, so I want to
send related patch to qemu mailing
list without binutils disassembler integration.
For me, I guess, it is legal.
Thanks.
On 2/17/15 11:11, Chen Gang S wrote:
> On 2/17/15 10:48, Chen Gang S wrote:
>> On 2/17/15 08:11, Chris Metcalf wrote:
>>> On 2/16/2015 6:46 PM, Peter Maydell
On 2/17/15 10:48, Chen Gang S wrote:
> On 2/17/15 08:11, Chris Metcalf wrote:
>> On 2/16/2015 6:46 PM, Peter Maydell wrote:
>>> On 17 February 2015 at 08:08, Chen Gang S wrote:
>>>> On 2/16/15 23:24, Max Filippov wrote:
>>>>> Disassembler is not a cr
On 2/17/15 10:15, Richard Henderson wrote:
> On 02/16/2015 02:51 PM, Chen Gang S wrote:
>> And excuse me, I still want to know, is there a real world register as a
>> PC register for tile (e.g. just like 'rip' for x86_64) which can be used
>> by software program
On 2/17/15 08:11, Chris Metcalf wrote:
> On 2/16/2015 6:46 PM, Peter Maydell wrote:
>> On 17 February 2015 at 08:08, Chen Gang S wrote:
>>> On 2/16/15 23:24, Max Filippov wrote:
>>>> Disassembler is not a crucial part of QEMU target.
>>> For me, it is neces
On 2/17/15 08:28, Chris Metcalf wrote:
> On 2/16/2015 5:51 PM, Chen Gang S wrote:
>
>> And excuse me, I still want to know, is there a real world register as a
>> PC register for tile (e.g. just like 'rip' for x86_64) which can be used
>> by software programer
on qemu before trying to make a case for it internally, though.
>
OK, thanks.
> On 2/15/2015 10:40 PM, Chen Gang S wrote:
>> Excuse me, I want to consult the related information about SPR.
>>
>> For SPRs (Special Purpose Register) under tilegx, I can not get related
>&
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
On 2/16/15 23:24, Max Filippov wrote:
> On Mon, Feb 16, 2015 at 5:44 PM, Chen Gang S wrote:
>> 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
On 2/17/15 00:25, Richard Henderson wrote:
> On 02/16/2015 05:49 AM, Chen Gang S wrote:
>> +#define TILEGX_R_PC 55 /* LR register, pc pointer */
>
> No, register 55 is the link register, not the PC.
> I.e. it is only special in that it receives the
> return address from
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.
Thanks.
On 2/16/15 11:40, Chen Gang S wrote:
> Excuse me, I want to consult the related information about SPR.
>
> For SPRs (S
They are based on Linux kernel tilegx architecture for 64 bit binary,
also based on tilegx ABI reference document.
Signed-off-by: Chen Gang
---
linux-user/tilegx/syscall.h| 80
linux-user/tilegx/syscall_nr.h | 278
linux-user/tilegx/term
For tilegx, several syscall macros are not supported, so switch them to
avoid building break.
Signed-off-by: Chen Gang
---
linux-user/syscall.c | 50 +-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux-user
Add main working flow feature and loading elf64 tilegx binary feature,
based on Linux kernel tilegx 64-bit implementation.
After this patch, qemu can successfully load elf64 tilegx binary for
linux-user, and the working flow reaches the first correct instruction
position "__start".
Signed-off-by:
Add tilegx architecture in "syscall_defs.h", all related features (ioctrl,
and stat) are based on Linux kernel tilegx 64-bit implementation.
Signed-off-by: Chen Gang
---
linux-user/syscall_defs.h | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff
They are for target features within qemu which independent from outside.
Signed-off-by: Chen Gang
---
linux-user/tilegx/target_cpu.h | 35 +++
linux-user/tilegx/target_signal.h | 28 ++
linux-user/tilegx/target_structs.h | 48 +
It almost likes a template for adding an architecture target.
Signed-off-by: Chen Gang
---
configure | 7 ++
default-configs/tilegx-linux-user.mak | 1 +
target-tilegx/Makefile.objs | 1 +
target-tilegx/cpu-qom.h | 72 +++
ta
After load elf64 tilegx binary for linux-user, the working flow reaches
1st correct instruction "__start". Next, we shall load all instructions
for qemu using.
This patch is based on Linux kernel tile architecture tilegx 64-bit
implementation, and also based on tilegx architecture ABI reference.
/tile/include/uapi/arch/spr_def_64.h".
- SPRs are all 64-bit registers (I referenced the 'interrupt_mask' and
CHIP_HAS_SPLIT_INTR_MASK to know about it).
If what I guess is incorrect, please let me know. And welcome to provide
tilegx SPR related documents, too.
Thanks.
On 2/14/1
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
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 wrote:
>>>> On 2/13/15 05:15, Chen Gang S wrote:
>>>>> It almost likes
On 2/14/15 10:40, Richard Henderson wrote:
> On 02/13/2015 04:26 PM, Peter Maydell wrote:
>>> 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 n
On 2/14/15 08:26, Peter Maydell wrote:
> On 13 February 2015 at 23:50, Chen Gang S 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
>>> -
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
> ---
> configure | 7 ++
> default-configs/tilegx-linux-user.mak | 1 +
> target-tile/Makefile.objs
On 2/13/15 13:43, Peter Maydell wrote:
> On 13 February 2015 at 05:44, Chen Gang S wrote:
>> Which issue of correctness will occur? I can not enum it.
>
> If the Linux kernel does not implement these syscalls then
> QEMU must not either. Attempting them should fail, same as
On 2/13/15 12:56, Peter Maydell wrote:
> On 13 February 2015 at 04:43, Chen Gang S wrote:
>> Originally, I have tried to remove TARGET_NR_open and others, they can
>> not pass building, and I also noticed about NR_openat. But at last, I
>> still remain TARGET_NR_open and
On 2/13/15 06:31, Chris Metcalf wrote:
> On 2/11/2015 10:32 PM, Chen Gang S wrote:
>> And excuse me, my English is not quite well, I don't quite understand:
>>
>>"fixing anything that breaks as a result".
>>
>> Could you provide more details? Tha
On 2/13/15 06:32, Chris Metcalf wrote:
> On 2/11/2015 10:48 PM, Chen Gang S wrote:
>> On 2/12/15 11:32, Chen Gang S wrote:
>>>>>>> >>> >> +#define EM_TILE 191 /* Tile */
>>>>>>> >>> >>+#define EM_TILE_OLD
Gang S
To: Peter Maydell , Riku Voipio ,
Chris Metcalf , w...@tilera.com
CC: qemu-devel
They are based on Linux kernel tilegx architecture for 64 bit binary,
also based on tilegx ABI reference document.
Signed-off-by: Chen Gang
---
linux-user/tile/syscall.h| 80 +++
linux-user
Add main working flow feature and loading elf64 tilegx binary feature,
based on Linux kernel tilegx 64-bit implementation.
After this patch, qemu can successfully load elf64 tilegx binary for
linux-user, and the working flow reaches 1st instruction "__start".
Signed-off-by: Chen Gang
---
includ
Add tile architecture in "syscall_defs.h", all related features (ioctrl,
and stat) are based on Linux kernel tilegx 64-bit implementation.
Signed-off-by: Chen Gang
---
linux-user/syscall_defs.h | 34 +++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git
They are for target features within qemu which independent from outside.
Signed-off-by: Chen Gang
---
linux-user/tile/target_cpu.h | 35 +
linux-user/tile/target_signal.h | 28 +++
linux-user/tile/target_structs.h | 48
It almost likes a template for adding an architecture target.
Signed-off-by: Chen Gang
---
configure | 7 ++
default-configs/tilegx-linux-user.mak | 1 +
target-tile/Makefile.objs | 1 +
target-tile/cpu-qom.h | 72 +++
ta
After load elf64 tilegx binary for linux-user, the working flow reaches
1st correct instruction "__start". Next, we shall load all instructions
for qemu using.
This patch is based on Linux kernel tile architecture tilegx 64-bit
implementation, and also based on tilegx architecture ABI reference.
On 2/12/15 11:32, Chen Gang S wrote:
>>> >> +#define EM_TILE 191 /* Tile */
>>> >> +#define EM_TILE_OLD 0x2597 /* Tile compat */
>> >
>> > No need for EM_TILE_OLD - it never really got out into the wild.
>> >
>> >
On 2/12/15 08:24, Chris Metcalf wrote:
> On 2/12/15 08:00, Chen Gang S wrote:
>> After load elf64 tilegx binary for linux-user, the working flow reaches
>> the first correct instruction postion "__start".
>
> Congratulations on getting started. I hope you have suc
On 2/12/15 08:49, Peter Maydell wrote:
> On 12 February 2015 at 00:00, Chen Gang S wrote:
>> After load elf64 tilegx binary for linux-user, the working flow reaches
>> the first correct instruction postion "__start". Next, we shall load all
>> instructions for qemu
Oh, sorry, I forgot to Cc to tile related members.
Thanks.
On 2/12/15 08:00, Chen Gang S wrote:
> After load elf64 tilegx binary for linux-user, the working flow reaches
> the first correct instruction postion "__start". Next, we shall load all
> instructions for qemu using.
After load elf64 tilegx binary for linux-user, the working flow reaches
the first correct instruction postion "__start". Next, we shall load all
instructions for qemu using.
This patch is based on Linux kernel tile architecture tilegx 64-bit
implementation, and also based on tilegx architecture AB
On 1/29/15 09:37, Chen Gang S wrote:
> On 1/29/15 06:36, Peter Maydell wrote:
>> On 28 January 2015 at 22:09, Chen Gang S wrote:
>>> - Is what I said above really correct (e.g. is linux-user really mainly
>>>for cpu emulation)?.
>>
>> Not really. linux-
On 1/29/15 06:36, Peter Maydell wrote:
> On 28 January 2015 at 22:09, Chen Gang S wrote:
>> - Is what I said above really correct (e.g. is linux-user really mainly
>>for cpu emulation)?.
>
> Not really. linux-user is mainly for running single Linux binaries.
> It
Hi,
>
> First of all, thanks Chen for taking time to improve the linux-user
> codebase in qemu!
>
> On Mon, Jan 26, 2015 at 03:01:52PM +, Peter Maydell wrote:
>> On 26 January 2015 at 14:59, Chen Gang S wrote:
>>> On 1/26/15 06:10, Peter Maydell wrote:
>>
On 1/28/15 00:11, Michael Tokarev wrote:
> 25.01.2015 14:03, Chen Gang S wrote:
>> start/end_exclusive() need be pairs, except the start_exclusive() in
>
> "need TO be pairs", or "should be pairs" or "should be called in pairs".
>
>> sto
Firstly, thank you for your work about the related patches and replying
so much details.
On 1/27/15 19:04, Michael Tokarev wrote:
> 23.01.2015 13:01, Chen Gang S wrote:
>> When failure occurs during allocating vec[i], also need free all
>> allocated vec[i] in failure processing co
On 1/26/15 23:01, Peter Maydell wrote:
> On 26 January 2015 at 14:59, Chen Gang S wrote:
>> On 1/26/15 06:10, Peter Maydell wrote:
>>> I would just like the commit message to be clear about the
>>> scope of the work the patch covers. If the patch is just "Fix
>
On 1/26/15 06:10, Peter Maydell wrote:
> On 25 January 2015 at 21:59, Chen Gang S wrote:
>> On 1/25/15 20:49, Peter Maydell wrote:
>>> Are you claiming that you've reviewed *all* the code in this
>>> file for mismatched lock/unlock calls? If so, it would be nice
On 1/25/15 20:49, Peter Maydell wrote:
> On 25 January 2015 at 12:06, Chen Gang S wrote:
>> lock_user_struct() and unlock_user_struct() need always be paired with
>> each other, or will cause resource leak.
>>
>> Also remove redundant check for 'target_mb'
lock_user_struct() and unlock_user_struct() need always be paired with
each other, or will cause resource leak.
Also remove redundant check for 'target_mb' in abi_long do_msgrcv().
Also match the coding styles found by "./scripts/checkpatch.pl".
Signed-off-by: Chen Gang
---
linux-user/syscall.
In main.c, all SIG* need be change to TARGET_SIG*, since the related
next call are all for TARGET_SIG*: queue_signal() and gdb_handlesig().
The related vi operation command is "1,$ s/\
---
linux-user/main.c | 64 +++
1 file changed, 32 insertion
start/end_exclusive() need be pairs, except the start_exclusive() in
stop_all_tasks() which is only used by force_sig(), which will be abort.
So at present, start_exclusive() in stop_all_task() need not be paired.
queue_signal() may call force_sig(), or return after kill pid (or queue
signal). If
In abi_long do_ioctl_dm(), after calls lock_user(), it does not call
unlock_user() before go to failure return in default case.
Signed-off-by: Chen Gang
---
linux-user/syscall.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index a427f7a..ec9e4
On 1/23/15 21:55, Peter Maydell wrote:
> On 23 January 2015 at 14:01, Chen Gang S wrote:
>> What I shall do for tile qemu should obey the related license of qemu
>> (all the related code should belong to qemu upstream). If necessary to
>> follow some copyright working flow,
On 1/23/15 19:21, Peter Maydell wrote:
> On 23 January 2015 at 10:57, Chen Gang S wrote:
>>
>> Thank you for all of your work.
>>
>> I plan to let qemu support tile architecture: "can let gcc run testsuite
>> with qemu for tile". It is really hard to me
inally, someone tried
qemu for tile, but the related code was not merged into main line.
- Suggestions about the schedule: the common steps, the time resources
may need, and which risks have to face to.
Thanks.
On 1/23/15 18:08, Peter Maydell wrote:
> On 23 January 2015 at 10:07,
On 1/23/15 18:20, Peter Maydell wrote:
> On 23 January 2015 at 10:17, Chen Gang S wrote:
>> start/end_exclusive() need be pairs, except the start_exclusive() in
>> stop_all_tasks() which is only used by force_sig(), which will be abort.
>> So at present, start_exclusive() in
On 1/23/15 18:01, Peter Maydell wrote:
> On 23 January 2015 at 08:53, Chen Gang S wrote:
>> In abi_long do_ioctl_dm(), after calls lock_user(), it does not call
>> unlock_user() before go to failure return in default case.
>>
>> Signed-off-by: Chen Gang
>>
start/end_exclusive() need be pairs, except the start_exclusive() in
stop_all_tasks() which is only used by force_sig(), which will be abort.
So at present, start_exclusive() in stop_all_task() need not be paired.
So need remove end_exclusive() after queue_signal(). If could really
return from que
It is only a typo issue, need use tswapal(target_vec[i].iov_len) for the
len.
Signed-off-by: Chen Gang
---
linux-user/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index a66c2ae..8260ed7 100644
--- a/linux-user/syscall.c
When failure occurs during allocating vec[i], also need free all
allocated vec[i] in failure processing code block before return.
In unlock_user(), it will check vec[i].iov_base whether is NULL, so need
not check it again outside.
If error is EFAULT when "i == 0", vec[i].iov_base is NULL, then ca
On 1/23/15 17:36, Chen Gang S wrote:
> When failure occurs during allocating vec[i], also need free all
> allocated vec[i] in failure processing code block before return.
>
> If error is EFAULT when "i == 0", vec[i].iov_base is NULL, then can just
> skip it, so can s
1 - 100 of 103 matches
Mail list logo
