[PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

  * microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
  'VOID' for operand 1, just like 'call_internal1' has done.

The related warning:

  ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode?


Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
 gcc/config/microblaze/microblaze.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
index 2bd5d72..9580221 100644
--- a/gcc/config/microblaze/microblaze.md
+++ b/gcc/config/microblaze/microblaze.md
@@ -2171,7 +2171,7 @@
 
 (define_insn "call_value_intern"
   [(set (match_operand:VOID 0 "register_operand" "=d")
-        (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
+        (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
               (match_operand:SI 2 "" "i")))
    (clobber (match_operand:SI 3 "register_operand" "=d"))]
   ""
-- 
1.7.11.7

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 07/06/14 03:26, Chen Gang wrote:
>
>    * microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
>    'VOID' for operand 1, just like 'call_internal1' has done.
>
> The related warning:
>
>    ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode?
>
>
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> ---
>   gcc/config/microblaze/microblaze.md | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
> index 2bd5d72..9580221 100644
> --- a/gcc/config/microblaze/microblaze.md
> +++ b/gcc/config/microblaze/microblaze.md
> @@ -2171,7 +2171,7 @@
>
>   (define_insn "call_value_intern"
>     [(set (match_operand:VOID 0 "register_operand" "=d")
> -        (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
> +        (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
>                 (match_operand:SI 2 "" "i")))
>      (clobber (match_operand:SI 3 "register_operand" "=d"))]
>     ""

This patch causes a test suite regression:

Executing on host: mb-gcc  -fno-diagnostics-show-caret -fdiagnostics-color=never    -O0  -w -c 
-mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a   -o calls.o 
testsuite/gcc.c-torture/compile/calls.c    (timeout = 60)
pid is 24832 -24832
testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
(call_insn 5 2 8 2 (parallel [
             (set (reg:SI 3 r3)
                 (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
                     (const_int 24 [0x18])))
             (clobber (reg:SI 15 r15))
         ]) testsuite/gcc.c-torture/compile/calls.c:5 -1
      (nil)
     (nil))
testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
	/store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
	/store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
0x9539cd extract_insn(rtx_def*)
	/store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
0x7a5b59 instantiate_virtual_regs_in_insn
	/store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
0x7aaa78 instantiate_virtual_regs
	/store/Xilinx/repo/fsf/gcc/gcc/function.c:1932



-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

Firstly, thank you very much for spending your time resource on the
related 2 patches.

On 8/13/14 23:10, Michael Eager wrote:
> On 07/06/14 03:26, Chen Gang wrote:
>>
>>    * microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
>>    'VOID' for operand 1, just like 'call_internal1' has done.
>>
>> The related warning:
>>
>>    ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode?
>>
>>
>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>> ---
>>   gcc/config/microblaze/microblaze.md | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
>> index 2bd5d72..9580221 100644
>> --- a/gcc/config/microblaze/microblaze.md
>> +++ b/gcc/config/microblaze/microblaze.md
>> @@ -2171,7 +2171,7 @@
>>
>>   (define_insn "call_value_intern"
>>     [(set (match_operand:VOID 0 "register_operand" "=d")
>> -        (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
>> +        (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
>>                 (match_operand:SI 2 "" "i")))
>>      (clobber (match_operand:SI 3 "register_operand" "=d"))]
>>     ""
> 
> This patch causes a test suite regression:
> 
> Executing on host: mb-gcc  -fno-diagnostics-show-caret -fdiagnostics-color=never    -O0  -w -c -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a   -o calls.o testsuite/gcc.c-torture/compile/calls.c    (timeout = 60)
> pid is 24832 -24832
> testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
> testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
> (call_insn 5 2 8 2 (parallel [
>             (set (reg:SI 3 r3)
>                 (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
>                     (const_int 24 [0x18])))
>             (clobber (reg:SI 15 r15))
>         ]) testsuite/gcc.c-torture/compile/calls.c:5 -1
>      (nil)
>     (nil))
> testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
> 0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>     /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
> 0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>     /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
> 0x9539cd extract_insn(rtx_def*)
>     /store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
> 0x7a5b59 instantiate_virtual_regs_in_insn
>     /store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
> 0x7aaa78 instantiate_virtual_regs
>     /store/Xilinx/repo/fsf/gcc/gcc/function.c:1932
>

OK, thanks, and I shall analyze it, but excuse me, I have to do other
things this week, so hope I can finish it within next week (2014-08-24).
If this time point is too long to bare, please let me know.


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 08/13/14 18:35, Chen Gang wrote:
>
> Firstly, thank you very much for spending your time resource on the
> related 2 patches.

You're welcome.

>
> On 8/13/14 23:10, Michael Eager wrote:
>> On 07/06/14 03:26, Chen Gang wrote:
>>>
>>>     * microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
>>>     'VOID' for operand 1, just like 'call_internal1' has done.
>>>
>>> The related warning:
>>>
>>>     ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode?
>>>
>>>
>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>> ---
>>>    gcc/config/microblaze/microblaze.md | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
>>> index 2bd5d72..9580221 100644
>>> --- a/gcc/config/microblaze/microblaze.md
>>> +++ b/gcc/config/microblaze/microblaze.md
>>> @@ -2171,7 +2171,7 @@
>>>
>>>    (define_insn "call_value_intern"
>>>      [(set (match_operand:VOID 0 "register_operand" "=d")
>>> -        (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
>>> +        (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
>>>                  (match_operand:SI 2 "" "i")))
>>>       (clobber (match_operand:SI 3 "register_operand" "=d"))]
>>>      ""
>>
>> This patch causes a test suite regression:
>>
>> Executing on host: mb-gcc  -fno-diagnostics-show-caret -fdiagnostics-color=never    -O0  -w -c -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a   -o calls.o testsuite/gcc.c-torture/compile/calls.c    (timeout = 60)
>> pid is 24832 -24832
>> testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
>> testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
>> (call_insn 5 2 8 2 (parallel [
>>              (set (reg:SI 3 r3)
>>                  (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
>>                      (const_int 24 [0x18])))
>>              (clobber (reg:SI 15 r15))
>>          ]) testsuite/gcc.c-torture/compile/calls.c:5 -1
>>       (nil)
>>      (nil))
>> testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
>> 0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>>      /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
>> 0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>>      /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
>> 0x9539cd extract_insn(rtx_def*)
>>      /store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
>> 0x7a5b59 instantiate_virtual_regs_in_insn
>>      /store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
>> 0x7aaa78 instantiate_virtual_regs
>>      /store/Xilinx/repo/fsf/gcc/gcc/function.c:1932
>>
>
> OK, thanks, and I shall analyze it, but excuse me, I have to do other
> things this week, so hope I can finish it within next week (2014-08-24).
> If this time point is too long to bare, please let me know.

Take your time and let me know when you have this resolved.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 8/14/14 10:14, Michael Eager wrote:
>> OK, thanks, and I shall analyze it, but excuse me, I have to do other
>> things this week, so hope I can finish it within next week (2014-08-24).
>> If this time point is too long to bare, please let me know.
> 
> Take your time and let me know when you have this resolved.

OK, thanks. I shall try to finish within next week (2014-08-24).


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

> On 8/13/14 23:10, Michael Eager wrote:
>> On 07/06/14 03:26, Chen Gang wrote:
>>>
>>>    * microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
>>>    'VOID' for operand 1, just like 'call_internal1' has done.
>>>
>>> The related warning:
>>>
>>>    ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode?
>>>
>>>
>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>> ---
>>>   gcc/config/microblaze/microblaze.md | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
>>> index 2bd5d72..9580221 100644
>>> --- a/gcc/config/microblaze/microblaze.md
>>> +++ b/gcc/config/microblaze/microblaze.md
>>> @@ -2171,7 +2171,7 @@
>>>
>>>   (define_insn "call_value_intern"
>>>     [(set (match_operand:VOID 0 "register_operand" "=d")
>>> -        (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
>>> +        (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
>>>                 (match_operand:SI 2 "" "i")))
>>>      (clobber (match_operand:SI 3 "register_operand" "=d"))]
>>>     ""
>>
>> This patch causes a test suite regression:
>>
>> Executing on host: mb-gcc  -fno-diagnostics-show-caret -fdiagnostics-color=never    -O0  -w -c -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a   -o calls.o testsuite/gcc.c-torture/compile/calls.c    (timeout = 60)
>> pid is 24832 -24832
>> testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
>> testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
>> (call_insn 5 2 8 2 (parallel [
>>             (set (reg:SI 3 r3)
>>                 (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
>>                     (const_int 24 [0x18])))
>>             (clobber (reg:SI 15 r15))
>>         ]) testsuite/gcc.c-torture/compile/calls.c:5 -1
>>      (nil)
>>     (nil))
>> testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
>> 0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>>     /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
>> 0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>>     /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
>> 0x9539cd extract_insn(rtx_def*)
>>     /store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
>> 0x7a5b59 instantiate_virtual_regs_in_insn
>>     /store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
>> 0x7aaa78 instantiate_virtual_regs
>>     /store/Xilinx/repo/fsf/gcc/gcc/function.c:1932
>>

It is really this patch to cause this issue. After add this patch, it
will be fail for compiling the below C code:

  typedef void  (*T)(void);
  f1 ()
  {
    ((T) 0)();
  }

And I guess, the original compiling warning is still useful for us: for
the almost same code, the original gcc (no this patch) also report the
same error:

  f1 ()
  {
    ((void (*)(void))0)();
  }

The related command is "./cc1 call.c -o /tmp/test.s" ('call.c' has the
contents above).


And I shall continue analysing it (I shall try to finish within this
month). And also welcome any ideas, suggestions or completions.

Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 09/07/2014 11:17 PM, Chen Gang wrote:
>> On 8/13/14 23:10, Michael Eager wrote:
>>> On 07/06/14 03:26, Chen Gang wrote:
>>>>
>>>>    * microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
>>>>    'VOID' for operand 1, just like 'call_internal1' has done.
>>>>
>>>> The related warning:
>>>>
>>>>    ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode?
>>>>
>>>>
>>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>>> ---
>>>>   gcc/config/microblaze/microblaze.md | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
>>>> index 2bd5d72..9580221 100644
>>>> --- a/gcc/config/microblaze/microblaze.md
>>>> +++ b/gcc/config/microblaze/microblaze.md
>>>> @@ -2171,7 +2171,7 @@
>>>>
>>>>   (define_insn "call_value_intern"
>>>>     [(set (match_operand:VOID 0 "register_operand" "=d")
>>>> -        (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
>>>> +        (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
>>>>                 (match_operand:SI 2 "" "i")))
>>>>      (clobber (match_operand:SI 3 "register_operand" "=d"))]
>>>>     ""
>>>
>>> This patch causes a test suite regression:
>>>
>>> Executing on host: mb-gcc  -fno-diagnostics-show-caret -fdiagnostics-color=never    -O0  -w -c -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a   -o calls.o testsuite/gcc.c-torture/compile/calls.c    (timeout = 60)
>>> pid is 24832 -24832
>>> testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
>>> testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
>>> (call_insn 5 2 8 2 (parallel [
>>>             (set (reg:SI 3 r3)
>>>                 (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
>>>                     (const_int 24 [0x18])))
>>>             (clobber (reg:SI 15 r15))
>>>         ]) testsuite/gcc.c-torture/compile/calls.c:5 -1
>>>      (nil)
>>>     (nil))
>>> testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
>>> 0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>>>     /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
>>> 0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>>>     /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
>>> 0x9539cd extract_insn(rtx_def*)
>>>     /store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
>>> 0x7a5b59 instantiate_virtual_regs_in_insn
>>>     /store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
>>> 0x7aaa78 instantiate_virtual_regs
>>>     /store/Xilinx/repo/fsf/gcc/gcc/function.c:1932
>>>
> 
> It is really this patch to cause this issue. After add this patch, it
> will be fail for compiling the below C code:
> 
>   typedef void  (*T)(void);
>   f1 ()
>   {
>     ((T) 0)();
>   }
> 

Oh, sorry, neither original nor the new one (with this patch) can
recognize the code above.

 - The original one can recognize "void *(*)(void);"

 - But can not recognize "void (*)(void);"

 - Although new one (with this patch) also recognize "void *(*)(void);",
   it causes inconsistency within "config/microblaze/microblaze.md".

And the original one also can recognize all below contents (only except
"void (*)(void), or void (*)(int)"):

 - void **(*)(void);

 - int *(*)(void);

 - int (*)(void);

 - int (*)(int);


> And I guess, the original compiling warning is still useful for us: for
> the almost same code, the original gcc (no this patch) also report the
> same error:
> 
>   f1 ()
>   {
>     ((void (*)(void))0)();
>   }
> 
> The related command is "./cc1 call.c -o /tmp/test.s" ('call.c' has the
> contents above).
> 
> 
> And I shall continue analysing it (I shall try to finish within this
> month). And also welcome any ideas, suggestions or completions.
> 
> Thanks.
> 


-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 09/08/2014 10:24 AM, Chen Gang wrote:
> On 09/07/2014 11:17 PM, Chen Gang wrote:
>>> On 8/13/14 23:10, Michael Eager wrote:
>>>> On 07/06/14 03:26, Chen Gang wrote:
>>>>>
>>>>>    * microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
>>>>>    'VOID' for operand 1, just like 'call_internal1' has done.
>>>>>
>>>>> The related warning:
>>>>>
>>>>>    ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode?
>>>>>
>>>>>
>>>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>>>> ---
>>>>>   gcc/config/microblaze/microblaze.md | 2 +-
>>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
>>>>> index 2bd5d72..9580221 100644
>>>>> --- a/gcc/config/microblaze/microblaze.md
>>>>> +++ b/gcc/config/microblaze/microblaze.md
>>>>> @@ -2171,7 +2171,7 @@
>>>>>
>>>>>   (define_insn "call_value_intern"
>>>>>     [(set (match_operand:VOID 0 "register_operand" "=d")
>>>>> -        (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
>>>>> +        (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
>>>>>                 (match_operand:SI 2 "" "i")))
>>>>>      (clobber (match_operand:SI 3 "register_operand" "=d"))]
>>>>>     ""
>>>>
>>>> This patch causes a test suite regression:
>>>>
>>>> Executing on host: mb-gcc  -fno-diagnostics-show-caret -fdiagnostics-color=never    -O0  -w -c -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a   -o calls.o testsuite/gcc.c-torture/compile/calls.c    (timeout = 60)
>>>> pid is 24832 -24832
>>>> testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
>>>> testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
>>>> (call_insn 5 2 8 2 (parallel [
>>>>             (set (reg:SI 3 r3)
>>>>                 (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
>>>>                     (const_int 24 [0x18])))
>>>>             (clobber (reg:SI 15 r15))
>>>>         ]) testsuite/gcc.c-torture/compile/calls.c:5 -1
>>>>      (nil)
>>>>     (nil))
>>>> testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
>>>> 0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>>>>     /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
>>>> 0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>>>>     /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
>>>> 0x9539cd extract_insn(rtx_def*)
>>>>     /store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
>>>> 0x7a5b59 instantiate_virtual_regs_in_insn
>>>>     /store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
>>>> 0x7aaa78 instantiate_virtual_regs
>>>>     /store/Xilinx/repo/fsf/gcc/gcc/function.c:1932
>>>>
>>

At present, I guess the original code is correct, need not additional
fix: "When call call_insn_operand() in gencog(), related 'rtx' mode is
VOIDmode (which need VOID, not SI)".

For the compiler's warning: "operand 1 is VOIDmode", after give some
related test, "operand 1 is VOIDmode" is all OK, the related tests are
below:

 - For almost same definitions, they are OK:

   - int *(*T)(void);

   - char *(*T)(int);

   ...

 - For incorrect assignments, report related correct warning/error:

   - char a = ((long long *(*)(short)) 0) (1);

   - ((long long *(*)(short)) 0) ();

   ...

If what I guess is correct, the below issue can be fixed in the same
way, please help check.

>>   typedef void  (*T)(void);
>>   f1 ()
>>   {
>>     ((T) 0)();
>>   }
>>
> 
> Oh, sorry, neither original nor the new one (with this patch) can
> recognize the code above.
> 

Need use VOID instead of SI, or when real VOIDmode comes, it does not
match SImode, so cause issue.

The related test code ('void' will cause CALL instead of SET):

  typedef void (*T)(void);
  f1 ()
  {
    ((T) 0)();
  }

The related error:

  [root@localhost gcc]# ./cc1 /tmp/calls.c -o /tmp/1.s
   f1
  Analyzing compilation unit
  Performing interprocedural optimizations
   <*free_lang_data> <visibility> <early_local_cleanups> <free-inline-summary> <whole-program> <inline>Assembling functions:
   f1
  /tmp/calls.c: In function 'f1':
  /tmp/calls.c:5:1: error: unrecognizable insn:
   }
   ^
  (call_insn 5 2 8 2 (parallel [
              (call (mem:SI (const_int 0 [0]) [0 MEM[(void (*<T29c>) (void))0B] S4 A32])
                  (const_int 24 [0x18]))
              (clobber (reg:SI 15 r15))
          ]) /tmp/calls.c:4 -1
       (nil)
      (nil))
  /tmp/calls.c:5:1: internal compiler error: in extract_insn, at recog.c:2204
  0xb0e71b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
  	../../gcc/gcc/rtl-error.c:109
  0xb0e75c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
  	../../gcc/gcc/rtl-error.c:117
  0xac552b extract_insn(rtx_def*)
  	../../gcc/gcc/recog.c:2204
  0x8b919e instantiate_virtual_regs_in_insn
  	../../gcc/gcc/function.c:1614
  0x8ba347 instantiate_virtual_regs
  	../../gcc/gcc/function.c:1934
  0x8ba452 execute
  	../../gcc/gcc/function.c:1983
  Please submit a full bug report,
  with preprocessed source if appropriate.
  Please include the complete backtrace with any bug report.
  See <http://gcc.gnu.org/bugs.html> for instructions.

diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
index b971737..3b4faf4 100644
--- a/gcc/config/microblaze/microblaze.md
+++ b/gcc/config/microblaze/microblaze.md
@@ -2062,7 +2062,7 @@
   (set_attr "length"   "4")])
 
 (define_insn "call_internal1"
-  [(call (mem (match_operand:SI 0 "call_insn_simple_operand" "ri"))
+  [(call (mem (match_operand:VOID 0 "call_insn_simple_operand" "ri"))
         (match_operand:SI 1 "" "i"))
   (clobber (reg:SI R_SR))]
   ""


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

Hello maintainers:

I also find some warnings during compiling microblaze, I also shall try
to fix them, but excuse me, I am not quite familiar the testsuite for
microblaze, could you provide any related information for it?

Thanks.

On 09/08/2014 11:28 PM, Chen Gang wrote:
> On 09/08/2014 10:24 AM, Chen Gang wrote:
>> On 09/07/2014 11:17 PM, Chen Gang wrote:
>>>> On 8/13/14 23:10, Michael Eager wrote:
>>>>> On 07/06/14 03:26, Chen Gang wrote:
>>>>>>
>>>>>>    * microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
>>>>>>    'VOID' for operand 1, just like 'call_internal1' has done.
>>>>>>
>>>>>> The related warning:
>>>>>>
>>>>>>    ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 missing mode?
>>>>>>
>>>>>>
>>>>>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>>>>>> ---
>>>>>>   gcc/config/microblaze/microblaze.md | 2 +-
>>>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
>>>>>> index 2bd5d72..9580221 100644
>>>>>> --- a/gcc/config/microblaze/microblaze.md
>>>>>> +++ b/gcc/config/microblaze/microblaze.md
>>>>>> @@ -2171,7 +2171,7 @@
>>>>>>
>>>>>>   (define_insn "call_value_intern"
>>>>>>     [(set (match_operand:VOID 0 "register_operand" "=d")
>>>>>> -        (call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
>>>>>> +        (call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
>>>>>>                 (match_operand:SI 2 "" "i")))
>>>>>>      (clobber (match_operand:SI 3 "register_operand" "=d"))]
>>>>>>     ""
>>>>>
>>>>> This patch causes a test suite regression:
>>>>>
>>>>> Executing on host: mb-gcc  -fno-diagnostics-show-caret -fdiagnostics-color=never    -O0  -w -c -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a   -o calls.o testsuite/gcc.c-torture/compile/calls.c    (timeout = 60)
>>>>> pid is 24832 -24832
>>>>> testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
>>>>> testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
>>>>> (call_insn 5 2 8 2 (parallel [
>>>>>             (set (reg:SI 3 r3)
>>>>>                 (call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*<T29e>) (void))0B] S4 A32])
>>>>>                     (const_int 24 [0x18])))
>>>>>             (clobber (reg:SI 15 r15))
>>>>>         ]) testsuite/gcc.c-torture/compile/calls.c:5 -1
>>>>>      (nil)
>>>>>     (nil))
>>>>> testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in extract_insn, at recog.c:2204
>>>>> 0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>>>>>     /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
>>>>> 0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>>>>>     /store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
>>>>> 0x9539cd extract_insn(rtx_def*)
>>>>>     /store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
>>>>> 0x7a5b59 instantiate_virtual_regs_in_insn
>>>>>     /store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
>>>>> 0x7aaa78 instantiate_virtual_regs
>>>>>     /store/Xilinx/repo/fsf/gcc/gcc/function.c:1932
>>>>>
>>>
> 
> At present, I guess the original code is correct, need not additional
> fix: "When call call_insn_operand() in gencog(), related 'rtx' mode is
> VOIDmode (which need VOID, not SI)".
> 
> For the compiler's warning: "operand 1 is VOIDmode", after give some
> related test, "operand 1 is VOIDmode" is all OK, the related tests are
> below:
> 
>  - For almost same definitions, they are OK:
> 
>    - int *(*T)(void);
> 
>    - char *(*T)(int);
> 
>    ...
> 
>  - For incorrect assignments, report related correct warning/error:
> 
>    - char a = ((long long *(*)(short)) 0) (1);
> 
>    - ((long long *(*)(short)) 0) ();
> 
>    ...
> 
> If what I guess is correct, the below issue can be fixed in the same
> way, please help check.
> 
>>>   typedef void  (*T)(void);
>>>   f1 ()
>>>   {
>>>     ((T) 0)();
>>>   }
>>>
>>
>> Oh, sorry, neither original nor the new one (with this patch) can
>> recognize the code above.
>>
> 
> Need use VOID instead of SI, or when real VOIDmode comes, it does not
> match SImode, so cause issue.
> 
> The related test code ('void' will cause CALL instead of SET):
> 
>   typedef void (*T)(void);
>   f1 ()
>   {
>     ((T) 0)();
>   }
> 
> The related error:
> 
>   [root@localhost gcc]# ./cc1 /tmp/calls.c -o /tmp/1.s
>    f1
>   Analyzing compilation unit
>   Performing interprocedural optimizations
>    <*free_lang_data> <visibility> <early_local_cleanups> <free-inline-summary> <whole-program> <inline>Assembling functions:
>    f1
>   /tmp/calls.c: In function 'f1':
>   /tmp/calls.c:5:1: error: unrecognizable insn:
>    }
>    ^
>   (call_insn 5 2 8 2 (parallel [
>               (call (mem:SI (const_int 0 [0]) [0 MEM[(void (*<T29c>) (void))0B] S4 A32])
>                   (const_int 24 [0x18]))
>               (clobber (reg:SI 15 r15))
>           ]) /tmp/calls.c:4 -1
>        (nil)
>       (nil))
>   /tmp/calls.c:5:1: internal compiler error: in extract_insn, at recog.c:2204
>   0xb0e71b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>   	../../gcc/gcc/rtl-error.c:109
>   0xb0e75c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>   	../../gcc/gcc/rtl-error.c:117
>   0xac552b extract_insn(rtx_def*)
>   	../../gcc/gcc/recog.c:2204
>   0x8b919e instantiate_virtual_regs_in_insn
>   	../../gcc/gcc/function.c:1614
>   0x8ba347 instantiate_virtual_regs
>   	../../gcc/gcc/function.c:1934
>   0x8ba452 execute
>   	../../gcc/gcc/function.c:1983
>   Please submit a full bug report,
>   with preprocessed source if appropriate.
>   Please include the complete backtrace with any bug report.
>   See <http://gcc.gnu.org/bugs.html> for instructions.
> 
> diff --git a/gcc/config/microblaze/microblaze.md b/gcc/config/microblaze/microblaze.md
> index b971737..3b4faf4 100644
> --- a/gcc/config/microblaze/microblaze.md
> +++ b/gcc/config/microblaze/microblaze.md
> @@ -2062,7 +2062,7 @@
>    (set_attr "length"   "4")])
>  
>  (define_insn "call_internal1"
> -  [(call (mem (match_operand:SI 0 "call_insn_simple_operand" "ri"))
> +  [(call (mem (match_operand:VOID 0 "call_insn_simple_operand" "ri"))
>          (match_operand:SI 1 "" "i"))
>    (clobber (reg:SI R_SR))]
>    ""
> 
> 
> Thanks.
> 


-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 09/14/14 00:51, Chen Gang wrote:
> Hello maintainers:
>
> I also find some warnings during compiling microblaze, I also shall try
> to fix them, but excuse me, I am not quite familiar the testsuite for
> microblaze, could you provide any related information for it?

Hi Chen --

This is the gcc DejaGNU test suite.  You can find info about DejaGNU
at http://www.gnu.org/software/dejagnu.  There is also info about
testing GCC here: https://gcc.gnu.org/wiki/Testing_GCC

Rather than the standard "make check-gcc" described on the wiki
page and elsewhere, I use a script which sets some configuration
options and executes runtest directly.  This uses a MicroBlaze processor
simulator called vpexec which was included with an older version of
Xilinx's EDK.  Xilinx no longer supports vpexec.

You can use a hardware target board to test microblaze-gcc,
or a different simulator such as QEMU.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 9/15/14 11:03, Michael Eager wrote:
> On 09/14/14 00:51, Chen Gang wrote:
>> Hello maintainers:
>>
>> I also find some warnings during compiling microblaze, I also shall try
>> to fix them, but excuse me, I am not quite familiar the testsuite for
>> microblaze, could you provide any related information for it?
> 
> Hi Chen --
> 
> This is the gcc DejaGNU test suite.  You can find info about DejaGNU
> at http://www.gnu.org/software/dejagnu.  There is also info about
> testing GCC here: https://gcc.gnu.org/wiki/Testing_GCC
> 

OK, thanks. I finished about x86_64 testsuite, and also tried microblaze
testsuite under x86_64 machine, but failed. Do I need any additional
information for microblaze testsuite?


> Rather than the standard "make check-gcc" described on the wiki
> page and elsewhere, I use a script which sets some configuration
> options and executes runtest directly.  This uses a MicroBlaze processor
> simulator called vpexec which was included with an older version of
> Xilinx's EDK.  Xilinx no longer supports vpexec.
> 
> You can use a hardware target board to test microblaze-gcc,
> or a different simulator such as QEMU.
> 

OK, thanks, I shall try Qemu (it is the additional chance for me to
familiar with Qemu).

And do you mean I need try testsuite under the related microblaze host (
e.g. Qemu microblaze simulator)?


After finish environments construction, I shall also try to test a patch
for "((void (*)(void)) 0)()" fixing.


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 09/14/14 21:19, Chen Gang wrote:
>
> On 9/15/14 11:03, Michael Eager wrote:
>> On 09/14/14 00:51, Chen Gang wrote:
>>> Hello maintainers:
>>>
>>> I also find some warnings during compiling microblaze, I also shall try
>>> to fix them, but excuse me, I am not quite familiar the testsuite for
>>> microblaze, could you provide any related information for it?
>>
>> Hi Chen --
>>
>> This is the gcc DejaGNU test suite.  You can find info about DejaGNU
>> at http://www.gnu.org/software/dejagnu.  There is also info about
>> testing GCC here: https://gcc.gnu.org/wiki/Testing_GCC
>>
>
> OK, thanks. I finished about x86_64 testsuite, and also tried microblaze
> testsuite under x86_64 machine, but failed. Do I need any additional
> information for microblaze testsuite?

I run tests using these options:
-mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a

Configuring DejaGNU for cross-target testing requires creating a configuration
file describing the target board.


>> Rather than the standard "make check-gcc" described on the wiki
>> page and elsewhere, I use a script which sets some configuration
>> options and executes runtest directly.  This uses a MicroBlaze processor
>> simulator called vpexec which was included with an older version of
>> Xilinx's EDK.  Xilinx no longer supports vpexec.
>>
>> You can use a hardware target board to test microblaze-gcc,
>> or a different simulator such as QEMU.
>>
>
> OK, thanks, I shall try Qemu (it is the additional chance for me to
> familiar with Qemu).
>
> And do you mean I need try testsuite under the related microblaze host (
> e.g. Qemu microblaze simulator)?
>
>
> After finish environments construction, I shall also try to test a patch
> for "((void (*)(void)) 0)()" fixing.
>
>
> Thanks.
>


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 09/15/2014 11:30 PM, Michael Eager wrote:
> On 09/14/14 21:19, Chen Gang wrote:
>>
>> On 9/15/14 11:03, Michael Eager wrote:
>>> On 09/14/14 00:51, Chen Gang wrote:
>>>> Hello maintainers:
>>>>
>>>> I also find some warnings during compiling microblaze, I also shall try
>>>> to fix them, but excuse me, I am not quite familiar the testsuite for
>>>> microblaze, could you provide any related information for it?
>>>
>>> Hi Chen --
>>>
>>> This is the gcc DejaGNU test suite.  You can find info about DejaGNU
>>> at http://www.gnu.org/software/dejagnu.  There is also info about
>>> testing GCC here: https://gcc.gnu.org/wiki/Testing_GCC
>>>
>>
>> OK, thanks. I finished about x86_64 testsuite, and also tried microblaze
>> testsuite under x86_64 machine, but failed. Do I need any additional
>> information for microblaze testsuite?
> 
> I run tests using these options:
> -mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a
> 

OK, thank you for your information.

> Configuring DejaGNU for cross-target testing requires creating a configuration
> file describing the target board.
> 

OK, thank you very much. And could you share your configuration file,
which I can reference to?


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

On 09/15/14 15:53, Chen Gang wrote:
> On 09/15/2014 11:30 PM, Michael Eager wrote:

>> Configuring DejaGNU for cross-target testing requires creating a configuration
>> file describing the target board.
>>
>
> OK, thank you very much. And could you share your configuration file,
> which I can reference to?

See attached.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

[-- Attachment #2: microblaze-xilinx-gdb.exp --]
[-- Type: text/plain, Size: 1614 bytes --]

# Xilinx remote for MicroBlaze using XMD

#load_generic_config "monitor"
load_generic_config "xmd"

# Identify multilib flags using libgloss
process_multilib_options ""

# The default compiler for this target.
set_board_info compiler  "mb-gcc"

# We will be using the standard GDB remote protocol
set_board_info gdb_protocol "remote"

# Name of the computer whose socket will be used, if required.
#set_board_info sockethost "gdb"
set_board_info sockethost "localhost"

# Port ID to use for socket connection
set_board_info gdb,socketport "1234"

# Port for target
#set_board_info netport "gdb:1234"
set_board_info netport "localhost:1234"

# Use techniques appropriate to a stub (don't do "run" command)
set_board_info use_gdb_stub 1

# This gdbserver can only run a process once per session.
set_board_info gdb,do_reload_on_run 1

# There's no support for argument-passing (yet).
set_board_info noargs 1

# Can't do input (or output) in the current gdbserver.
set_board_info gdb,noinferiorio 1

# Can't do singnals
set_board_info gdb,nosignals 1

# Can't do hardware watchpoints, in general
set_board_info gdb,no_hardware_watchpoints 1

#set_board_info cflags  "[newlib_include_flags] [libgloss_include_flags]"

set_board_info cflags  "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
set_board_info addl_link_flags "-L /home/eager/Xilinx/dg/microblaze_0/lib -Wl,-defsym -Wl,_HEAP_SIZE=0x1000000 -Wl,-defsym -Wl,_STACK_SIZE=0x80000"
set_board_info ldscript "-T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld"
set_board_info ldflags  "[libgloss_link_flags] [newlib_link_flags] [board_info $board addl_link_flags]"

[-- Attachment #3: xmd.exp --]
[-- Type: text/plain, Size: 519 bytes --]

#  Use remote protocol to XMD server

load_config "monitor.exp"

proc set_host_info { entry value } {
    global target_info board_info
    verbose "set_host_info $entry $value" 3

    set machine host
    if [info exists target_info($machine,name)] {
        set machine $target_info($machine,name)
    }
    set board_info($machine,$entry) $value
}

proc gdb_target_exec { } {
     send_gdb "cont"
#    gdb_test "target exec" "No executable file now." "" ".*Kill it.*y or n.*" "y"
}

proc remote_reboot { host } {
}

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 09/16/2014 08:33 PM, Michael Eager wrote:
> On 09/15/14 15:53, Chen Gang wrote:
>> On 09/15/2014 11:30 PM, Michael Eager wrote:
> 
>>> Configuring DejaGNU for cross-target testing requires creating a configuration
>>> file describing the target board.
>>>
>>
>> OK, thank you very much. And could you share your configuration file,
>> which I can reference to?
> 
> See attached.
> 

Thank you very much for your attachments, it is very useful to me!

I tried testsuite for microblaze cross target on x86_64 host, it says
OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
that my configuration is incorrect), please help check, thanks.

  dejagnu configuration:
  
    cp xmd.exp /usr/local/share/dejagnu/config/
    cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
    vi microblaze-xilinx-gdb.exp
      "s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
  
  gcc operation:
  
    ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \
      --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
    make
    make -k check-gcc RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"
  
  gcc result:
  
                 === gcc Summary ===
  
    # of expected passes          48408
    # of unexpected failures      17253
    # of unexpected successes     1
    # of expected failures        97
    # of unresolved testcases     16570
    # of unsupported tests        1854
    /upstream/build-gcc/gcc/xgcc  version 5.0.0 20140920 (experimental) (GCC) 
    
    make[2]: Leaving directory `/upstream/build-gcc/gcc'
    make[1]: Leaving directory `/upstream/build-gcc/gcc'
    [root@localhost build-gcc]# echo $?
    0


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 09/20/14 08:52, Chen Gang wrote:

> Thank you very much for your attachments, it is very useful to me!
>
> I tried testsuite for microblaze cross target on x86_64 host, it says
> OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
> that my configuration is incorrect), please help check, thanks.

Welcome to the joys of DejaGNU.  Configuration can be confusing.
As you can see, the return code is not useful.

>    dejagnu configuration:
>
>      cp xmd.exp /usr/local/share/dejagnu/config/
>      cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
>      vi microblaze-xilinx-gdb.exp
>        "s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
>
>    gcc operation:
>
>      ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \
>        --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
>      make
>      make -k check-gcc RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"

Check whether these compiler options are being passed to mb-gcc.  There is a
line in my microblaze-xilinx-gdb.exp which sets CFLAGS:
   set_board_info cflags  "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
This is likely overriding any options passed to runtest.

Make sure that the options match the features of your target board.  You might
not need any options for your initial tests.

Make sure that the correct flags are being passed to the linker.

Add "-v" or "-v -v" to RUNTESTFLAGS so that the gcc.log file gives useful info.

You might want to limit the number of tests run until you get problems worked out:
   make check-gcc RUNTESTFLAGS="execute.exp -v -v --target_board=microblaze-xilinx-gdb"
This will run only the gcc.c-torture/execute/execute.exp tests.

>    gcc result:
>
>                   === gcc Summary ===
>
>      # of expected passes          48408
>      # of unexpected failures      17253
>      # of unexpected successes     1
>      # of expected failures        97
>      # of unresolved testcases     16570
>      # of unsupported tests        1854
>      /upstream/build-gcc/gcc/xgcc  version 5.0.0 20140920 (experimental) (GCC)

Look at gcc.sum and gcc.log to find out what is causing the large number of
unexpected failures.  A large number of unresolved test cases often means that
the compiler returned an error.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

Thank you very much for your quickly response, I shall continue try.

Thanks.

On 09/21/2014 12:31 AM, Michael Eager wrote:
> On 09/20/14 08:52, Chen Gang wrote:
> 
>> Thank you very much for your attachments, it is very useful to me!
>>
>> I tried testsuite for microblaze cross target on x86_64 host, it says
>> OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
>> that my configuration is incorrect), please help check, thanks.
> 
> Welcome to the joys of DejaGNU.  Configuration can be confusing.
> As you can see, the return code is not useful.
> 
>>    dejagnu configuration:
>>
>>      cp xmd.exp /usr/local/share/dejagnu/config/
>>      cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
>>      vi microblaze-xilinx-gdb.exp
>>        "s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
>>
>>    gcc operation:
>>
>>      ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \
>>        --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
>>      make
>>      make -k check-gcc RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"
> 
> Check whether these compiler options are being passed to mb-gcc.  There is a
> line in my microblaze-xilinx-gdb.exp which sets CFLAGS:
>   set_board_info cflags  "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
> This is likely overriding any options passed to runtest.
> 
> Make sure that the options match the features of your target board.  You might
> not need any options for your initial tests.
> 
> Make sure that the correct flags are being passed to the linker.
> 
> Add "-v" or "-v -v" to RUNTESTFLAGS so that the gcc.log file gives useful info.
> 
> You might want to limit the number of tests run until you get problems worked out:
>   make check-gcc RUNTESTFLAGS="execute.exp -v -v --target_board=microblaze-xilinx-gdb"
> This will run only the gcc.c-torture/execute/execute.exp tests.
> 
>>    gcc result:
>>
>>                   === gcc Summary ===
>>
>>      # of expected passes          48408
>>      # of unexpected failures      17253
>>      # of unexpected successes     1
>>      # of expected failures        97
>>      # of unresolved testcases     16570
>>      # of unsupported tests        1854
>>      /upstream/build-gcc/gcc/xgcc  version 5.0.0 20140920 (experimental) (GCC)
> 
> Look at gcc.sum and gcc.log to find out what is causing the large number of
> unexpected failures.  A large number of unresolved test cases often means that
> the compiler returned an error.
> 


-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

After check the details, I guess, we need:

 - Cross compile and install glibc with raw microblaze cross-compiler,

 - Then compile new microblaze cross compiler with glibc.

 - Then make check the new microblaze cross compiler with glibc.

And it seems, we also need 'LinkScr.ld' for ldscript, could you share it
to me, thanks.

  set_board_info ldscript "-T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld"

At present, I am just analyzing how to cross compile microblaze glibc,
welcome any ideas, suggestions or completions.

Thanks.

On 09/21/2014 12:41 AM, Chen Gang wrote:
> 
> Thank you very much for your quickly response, I shall continue try.
> 
> Thanks.
> 
> On 09/21/2014 12:31 AM, Michael Eager wrote:
>> On 09/20/14 08:52, Chen Gang wrote:
>>
>>> Thank you very much for your attachments, it is very useful to me!
>>>
>>> I tried testsuite for microblaze cross target on x86_64 host, it says
>>> OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
>>> that my configuration is incorrect), please help check, thanks.
>>
>> Welcome to the joys of DejaGNU.  Configuration can be confusing.
>> As you can see, the return code is not useful.
>>
>>>    dejagnu configuration:
>>>
>>>      cp xmd.exp /usr/local/share/dejagnu/config/
>>>      cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
>>>      vi microblaze-xilinx-gdb.exp
>>>        "s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
>>>
>>>    gcc operation:
>>>
>>>      ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \
>>>        --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
>>>      make
>>>      make -k check-gcc RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"
>>
>> Check whether these compiler options are being passed to mb-gcc.  There is a
>> line in my microblaze-xilinx-gdb.exp which sets CFLAGS:
>>   set_board_info cflags  "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
>> This is likely overriding any options passed to runtest.
>>
>> Make sure that the options match the features of your target board.  You might
>> not need any options for your initial tests.
>>
>> Make sure that the correct flags are being passed to the linker.
>>
>> Add "-v" or "-v -v" to RUNTESTFLAGS so that the gcc.log file gives useful info.
>>
>> You might want to limit the number of tests run until you get problems worked out:
>>   make check-gcc RUNTESTFLAGS="execute.exp -v -v --target_board=microblaze-xilinx-gdb"
>> This will run only the gcc.c-torture/execute/execute.exp tests.
>>
>>>    gcc result:
>>>
>>>                   === gcc Summary ===
>>>
>>>      # of expected passes          48408
>>>      # of unexpected failures      17253
>>>      # of unexpected successes     1
>>>      # of expected failures        97
>>>      # of unresolved testcases     16570
>>>      # of unsupported tests        1854
>>>      /upstream/build-gcc/gcc/xgcc  version 5.0.0 20140920 (experimental) (GCC)
>>
>> Look at gcc.sum and gcc.log to find out what is causing the large number of
>> unexpected failures.  A large number of unresolved test cases often means that
>> the compiler returned an error.
>>
> 
> 


-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 09/21/2014 02:24 PM, Chen Gang wrote:
> 
> After check the details, I guess, we need:
> 
>  - Cross compile and install glibc with raw microblaze cross-compiler,
> 

After fix a compiling break bug for microblaze glibc, I succeed building
microblaze glibc with microblaze raw cross compiler, with latest Linux
upstream kernel header for microblaze (copy manually), under x86_64 host.

I have sent related patch for glibc mailing list, and continue the next
below, hope I can succeed. :-)  thanks.

>  - Then compile new microblaze cross compiler with glibc.
> 
>  - Then make check the new microblaze cross compiler with glibc.
> 
> And it seems, we also need 'LinkScr.ld' for ldscript, could you share it
> to me, thanks.
> 
>   set_board_info ldscript "-T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld"
> 
> At present, I am just analyzing how to cross compile microblaze glibc,
> welcome any ideas, suggestions or completions.
> 
> Thanks.
> 
> On 09/21/2014 12:41 AM, Chen Gang wrote:
>>
>> Thank you very much for your quickly response, I shall continue try.
>>
>> Thanks.
>>
>> On 09/21/2014 12:31 AM, Michael Eager wrote:
>>> On 09/20/14 08:52, Chen Gang wrote:
>>>
>>>> Thank you very much for your attachments, it is very useful to me!
>>>>
>>>> I tried testsuite for microblaze cross target on x86_64 host, it says
>>>> OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
>>>> that my configuration is incorrect), please help check, thanks.
>>>
>>> Welcome to the joys of DejaGNU.  Configuration can be confusing.
>>> As you can see, the return code is not useful.
>>>
>>>>    dejagnu configuration:
>>>>
>>>>      cp xmd.exp /usr/local/share/dejagnu/config/
>>>>      cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
>>>>      vi microblaze-xilinx-gdb.exp
>>>>        "s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
>>>>
>>>>    gcc operation:
>>>>
>>>>      ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \
>>>>        --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
>>>>      make
>>>>      make -k check-gcc RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"
>>>
>>> Check whether these compiler options are being passed to mb-gcc.  There is a
>>> line in my microblaze-xilinx-gdb.exp which sets CFLAGS:
>>>   set_board_info cflags  "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
>>> This is likely overriding any options passed to runtest.
>>>
>>> Make sure that the options match the features of your target board.  You might
>>> not need any options for your initial tests.
>>>
>>> Make sure that the correct flags are being passed to the linker.
>>>
>>> Add "-v" or "-v -v" to RUNTESTFLAGS so that the gcc.log file gives useful info.
>>>
>>> You might want to limit the number of tests run until you get problems worked out:
>>>   make check-gcc RUNTESTFLAGS="execute.exp -v -v --target_board=microblaze-xilinx-gdb"
>>> This will run only the gcc.c-torture/execute/execute.exp tests.
>>>
>>>>    gcc result:
>>>>
>>>>                   === gcc Summary ===
>>>>
>>>>      # of expected passes          48408
>>>>      # of unexpected failures      17253
>>>>      # of unexpected successes     1
>>>>      # of expected failures        97
>>>>      # of unresolved testcases     16570
>>>>      # of unsupported tests        1854
>>>>      /upstream/build-gcc/gcc/xgcc  version 5.0.0 20140920 (experimental) (GCC)
>>>
>>> Look at gcc.sum and gcc.log to find out what is causing the large number of
>>> unexpected failures.  A large number of unresolved test cases often means that
>>> the compiler returned an error.
>>>
>>
>>
> 
> 


-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 09/20/14 23:24, Chen Gang wrote:
> And it seems, we also need 'LinkScr.ld' for ldscript, could you share it
> to me, thanks.
>
>    set_board_info ldscript "-T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld"

Hi Chen --

The DejaGNU configuration I provided is for a bare-metal environment.

If you are testing in a Linux environment, the tool chain you uses
should provide a default linker script which matches your hardware's
memory layout. You should not need to provide a separate linker script.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 09/21/14 03:46, Chen Gang wrote:
> Excuse me, I want to consult one thing: I installed raw microblaze cross
> compiler, binutils and glibc into one directory (/upstream/release), and
> try to build a "Hello world" C program for microblaze under x86_64 host.
>
> I guess it is OK, but I am not quite sure about it (I use raw compiler,
> and have to point out "/upstream/release/lib/ld.so.1" explicitly, and
> receive a warning related with 'ld').
>
> Is it really OK? can I still use raw compiler for our testsuite? Is
> 'LinkScr.ld' for ldscript related with current case?


>    [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-gcc -nostdinc -c -o test.o test.c
>    [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-ld -o test test.o /upstream/release/lib/ld.so.1 -lc -L/upstream/release/lib
>
>      /upstream/release/bin/microblaze-gchen-linux-ld: warning: cannot find entry symbol _start; defaulting to 0000000010000180

Generally, you should use "gcc" to link programs, not "ld".  gcc is
a driver which will select the appropriate libraries and support routines
(such as crt0.o, which contains _start) and pass them to the linker.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 9/22/14 2:03, Michael Eager wrote:
> On 09/20/14 23:24, Chen Gang wrote:
>> And it seems, we also need 'LinkScr.ld' for ldscript, could you share it
>> to me, thanks.
>>
>>    set_board_info ldscript "-T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld"
> 
> Hi Chen --
> 
> The DejaGNU configuration I provided is for a bare-metal environment.
> 
> If you are testing in a Linux environment, the tool chain you uses
> should provide a default linker script which matches your hardware's
> memory layout. You should not need to provide a separate linker script.
> 

OK, thanks, I shall try to find the default linker script for it.

Thanks
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 9/22/14 2:09, Michael Eager wrote:
> On 09/21/14 03:46, Chen Gang wrote:
>> Excuse me, I want to consult one thing: I installed raw microblaze cross
>> compiler, binutils and glibc into one directory (/upstream/release), and
>> try to build a "Hello world" C program for microblaze under x86_64 host.
>>
>> I guess it is OK, but I am not quite sure about it (I use raw compiler,
>> and have to point out "/upstream/release/lib/ld.so.1" explicitly, and
>> receive a warning related with 'ld').
>>
>> Is it really OK? can I still use raw compiler for our testsuite? Is
>> 'LinkScr.ld' for ldscript related with current case?
> 
> 
>>    [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-gcc -nostdinc -c -o test.o test.c
>>    [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-ld -o test test.o /upstream/release/lib/ld.so.1 -lc -L/upstream/release/lib
>>
>>      /upstream/release/bin/microblaze-gchen-linux-ld: warning: cannot find entry symbol _start; defaulting to 0000000010000180
> 
> Generally, you should use "gcc" to link programs, not "ld".  gcc is
> a driver which will select the appropriate libraries and support routines
> (such as crt0.o, which contains _start) and pass them to the linker.
> 

OK, thanks.

When gcc, it misses the root directory for "crt1.o" and "crtn.o": e.g.
"/lib/ld.so.1", "crt1.o", "crtn.o" when gcc -v, but we need "/upstream/
release/lib/ld.so.1", "/upstream/lib/crt1.o", "/upstream/libcrtn.o".

I guess, we need additional flag to mark the default system link path
for gcc. But after check the all parameters of gcc, I can not find (-L
is for normal library linkage, but not for crt1.o and crtn.o).

I shall continue trying for it, and hope I can finish within this month.
Welcome any ideas, suggestions or completions.

Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 09/21/14 21:10, Chen Gang wrote:
> On 9/22/14 2:09, Michael Eager wrote:
>>
>> Generally, you should use "gcc" to link programs, not "ld".  gcc is
>> a driver which will select the appropriate libraries and support routines
>> (such as crt0.o, which contains _start) and pass them to the linker.
>>
>
> OK, thanks.
>
> When gcc, it misses the root directory for "crt1.o" and "crtn.o": e.g.
> "/lib/ld.so.1", "crt1.o", "crtn.o" when gcc -v, but we need "/upstream/
> release/lib/ld.so.1", "/upstream/lib/crt1.o", "/upstream/libcrtn.o".

You likely need to build mb-gcc with --sysroot=/upstream.

How are you building gcc?  What are your configuration options?


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 09/21/14 20:55, Chen Gang wrote:
>
>
> On 9/22/14 2:03, Michael Eager wrote:
>> On 09/20/14 23:24, Chen Gang wrote:
>>> And it seems, we also need 'LinkScr.ld' for ldscript, could you share it
>>> to me, thanks.
>>>
>>>     set_board_info ldscript "-T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld"
>>
>> Hi Chen --
>>
>> The DejaGNU configuration I provided is for a bare-metal environment.
>>
>> If you are testing in a Linux environment, the tool chain you uses
>> should provide a default linker script which matches your hardware's
>> memory layout. You should not need to provide a separate linker script.
>>
>
> OK, thanks, I shall try to find the default linker script for it.

If you are running mb-gcc which generates executables which run on
the target, you do not need to provide a linker script.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 09/22/2014 10:45 PM, Michael Eager wrote:
> On 09/21/14 21:10, Chen Gang wrote:
>> On 9/22/14 2:09, Michael Eager wrote:
>>>
>>> Generally, you should use "gcc" to link programs, not "ld".  gcc is
>>> a driver which will select the appropriate libraries and support routines
>>> (such as crt0.o, which contains _start) and pass them to the linker.
>>>
>>
>> OK, thanks.
>>
>> When gcc, it misses the root directory for "crt1.o" and "crtn.o": e.g.
>> "/lib/ld.so.1", "crt1.o", "crtn.o" when gcc -v, but we need "/upstream/
>> release/lib/ld.so.1", "/upstream/lib/crt1.o", "/upstream/libcrtn.o".
> 
> You likely need to build mb-gcc with --sysroot=/upstream.
> 

OK, thanks! I guess it will solve all issues which I met, and I shall
try next.

> How are you building gcc?  What are your configuration options?
> 

The related information is below, please help check when you have time,
thanks.

[root@localhost ~]# /upstream/release/bin/microblaze-gchen-linux-gcc -v
Using built-in specs.
COLLECT_GCC=/upstream/release/bin/microblaze-gchen-linux-gcc
COLLECT_LTO_WRAPPER=/upstream/release/libexec/gcc/microblaze-gchen-linux/5.0.0/lto-wrapper
Target: microblaze-gchen-linux
Configured with: ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic --prefix=/upstream/release
Thread model: single
gcc version 5.0.0 20140920 (experimental) (GCC) 
[root@localhost ~]# 


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 09/22/2014 10:46 PM, Michael Eager wrote:
> On 09/21/14 20:55, Chen Gang wrote:
>>
>>
>> On 9/22/14 2:03, Michael Eager wrote:
>>> On 09/20/14 23:24, Chen Gang wrote:
>>>> And it seems, we also need 'LinkScr.ld' for ldscript, could you share it
>>>> to me, thanks.
>>>>
>>>>     set_board_info ldscript "-T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld"
>>>
>>> Hi Chen --
>>>
>>> The DejaGNU configuration I provided is for a bare-metal environment.
>>>
>>> If you are testing in a Linux environment, the tool chain you uses
>>> should provide a default linker script which matches your hardware's
>>> memory layout. You should not need to provide a separate linker script.
>>>
>>
>> OK, thanks, I shall try to find the default linker script for it.
> 
> If you are running mb-gcc which generates executables which run on
> the target, you do not need to provide a linker script.
> 

OK, thanks. I shall remove it, next.

Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

Hello Michael:

Firstly, thank you very much for always providing your aid to me for
microblaze.

At present, after try testsuite, the result is much better than my
original trying, please help check the result: "is it enough for our
microblaze testsuite" (can we say it pass checking)?

  Current result:

    # of expected passes            65987
    # of unexpected failures        82
    # of unexpected successes       1
    # of expected failures          97
    # of unresolved testcases       16378
    # of unsupported tests          1810

  Original result:

    # of expected passes          48408
    # of unexpected failures      17253
    # of unexpected successes     1
    # of expected failures        97
    # of unresolved testcases     16570
    # of unsupported tests        1854

After check the current result log, I find many remote target test
related sentences, do we have to process it?

  e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."


>>
>> And I guess, it is a glibc bug: which still add root directory (e.g.
>> /upstream/release) in 'libc.so' when already has --with-sysroot for
>> configure.
>>
> 
> Oh, sorry, glibc should also need --with-sysroot. I shall try it today,
> hope it will let all things OK.
> 

After add --with-sysroot for glibc, this issue is still existance. And I
remove the redundant direcltory manually for libc.so and libpthread.so.

If our microblaze testsuite is OK, I will skip this issue (since I have
no enough time resource on glibc, at present).


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 09/24/14 07:31, Chen Gang wrote:
> Hello Michael:
>
> Firstly, thank you very much for always providing your aid to me for
> microblaze.
>
> At present, after try testsuite, the result is much better than my
> original trying, please help check the result: "is it enough for our
> microblaze testsuite" (can we say it pass checking)?
>
>    Current result:
>
>      # of expected passes            65987
>      # of unexpected failures        82
>      # of unexpected successes       1
>      # of expected failures          97
>      # of unresolved testcases       16378
>      # of unsupported tests          1810

This is good.

>
>    Original result:
>
>      # of expected passes          48408
>      # of unexpected failures      17253
>      # of unexpected successes     1
>      # of expected failures        97
>      # of unresolved testcases     16570
>      # of unsupported tests        1854
>
> After check the current result log, I find many remote target test
> related sentences, do we have to process it?
>
>    e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."

The test suite uses rcp to transfer files to or from the target,
either to provide input to a test case or to check the output.
Most Linux systems do not install rcp, since it is a security risk.

>>> And I guess, it is a glibc bug: which still add root directory (e.g.
>>> /upstream/release) in 'libc.so' when already has --with-sysroot for
>>> configure.
>>>
>>
>> Oh, sorry, glibc should also need --with-sysroot. I shall try it today,
>> hope it will let all things OK.
>>
>
> After add --with-sysroot for glibc, this issue is still existance. And I
> remove the redundant direcltory manually for libc.so and libpthread.so.
>
> If our microblaze testsuite is OK, I will skip this issue (since I have
> no enough time resource on glibc, at present).

OK with me.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Mike Stump]

On Sep 24, 2014, at 8:28 AM, Michael Eager <eager@eagerm.com> wrote:
>> After check the current result log, I find many remote target test
>> related sentences, do we have to process it?
>> 
>>   e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."
> 
> The test suite uses rcp to transfer files to or from the target,
> either to provide input to a test case or to check the output.
> Most Linux systems do not install rcp, since it is a security risk.

To clarify:

    if {[board_info $desthost exists rcp_prog]} {
        set RCP [board_info $desthost rcp_prog]
    } else {
        set RCP rcp
    }

So, if you set rcp_prog to something else, you should be able to avoid rsh if you want.  Most people use ssh now-a-days.  You will want it set up to not require a password for testing.

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 09/24/2014 11:28 PM, Michael Eager wrote:
> On 09/24/14 07:31, Chen Gang wrote:
>> Hello Michael:
>>
>> Firstly, thank you very much for always providing your aid to me for
>> microblaze.
>>
>> At present, after try testsuite, the result is much better than my
>> original trying, please help check the result: "is it enough for our
>> microblaze testsuite" (can we say it pass checking)?
>>
>>    Current result:
>>
>>      # of expected passes            65987
>>      # of unexpected failures        82
>>      # of unexpected successes       1
>>      # of expected failures          97
>>      # of unresolved testcases       16378
>>      # of unsupported tests          1810
> 
> This is good.
> 

OK, thanks, and I shall send a fix patch for "((void (*)(void))0)()"
tomorrow, it pass testsuite (old and new get the same result), but new
can fix "((void (*)(void))0)()" issue. So I guess this fix is valid. :-)


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 09/24/2014 11:37 PM, Mike Stump wrote:
> On Sep 24, 2014, at 8:28 AM, Michael Eager <eager@eagerm.com> wrote:
>>> After check the current result log, I find many remote target test
>>> related sentences, do we have to process it?
>>>
>>>   e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."
>>
>> The test suite uses rcp to transfer files to or from the target,
>> either to provide input to a test case or to check the output.
>> Most Linux systems do not install rcp, since it is a security risk.
> 
> To clarify:
> 
>     if {[board_info $desthost exists rcp_prog]} {
>         set RCP [board_info $desthost rcp_prog]
>     } else {
>         set RCP rcp
>     }
> 
> So, if you set rcp_prog to something else, you should be able to avoid rsh if you want.  Most people use ssh now-a-days.  You will want it set up to not require a password for testing.
> 

OK, thank you for your information.

For one simple solving way under fedora: "yum install rsh", and I will
get another issue:

  "Download to microblaze-xilinx-gdb failed, microblaze-xilinx-gdb: Unknown host"

So I guess the root cause is: I only use cross-compiling environments
under fedora x86_64, no any real or virtual target for test.


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Mike Stump]

On Sep 24, 2014, at 9:23 AM, Chen Gang <gang.chen.5i5j@gmail.com> wrote:
> For one simple solving way under fedora: "yum install rsh", and I will
> get another issue:
> 
>  "Download to microblaze-xilinx-gdb failed, microblaze-xilinx-gdb: Unknown host"
> 
> So I guess the root cause is: I only use cross-compiling environments
> under fedora x86_64, no any real or virtual target for test.

Yes, if you want to test on a target, you will need a target.  You can either have a simulator (see binutils and sim/* for an example of how to write one) or target hardware in some form.

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 09/24/14 09:23, Chen Gang wrote:
> On 09/24/2014 11:37 PM, Mike Stump wrote:
>> On Sep 24, 2014, at 8:28 AM, Michael Eager <eager@eagerm.com> wrote:
>>>> After check the current result log, I find many remote target test
>>>> related sentences, do we have to process it?
>>>>
>>>>    e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."
>>>
>>> The test suite uses rcp to transfer files to or from the target,
>>> either to provide input to a test case or to check the output.
>>> Most Linux systems do not install rcp, since it is a security risk.
>>
>> To clarify:
>>
>>      if {[board_info $desthost exists rcp_prog]} {
>>          set RCP [board_info $desthost rcp_prog]
>>      } else {
>>          set RCP rcp
>>      }
>>
>> So, if you set rcp_prog to something else, you should be able to avoid rsh if you want.  Most people use ssh now-a-days.  You will want it set up to not require a password for testing.
>>
>
> OK, thank you for your information.
>
> For one simple solving way under fedora: "yum install rsh", and I will
> get another issue:
>
>    "Download to microblaze-xilinx-gdb failed, microblaze-xilinx-gdb: Unknown host"
>
> So I guess the root cause is: I only use cross-compiling environments
> under fedora x86_64, no any real or virtual target for test.

You can see the command which is getting the error by looking at gcc.log.
If the command is not displayed, add another "-v" (or two) to RUNTESTFLAGS.

If I recall correctly, DejaGNU is executing a command like "rcp file microblaze-xilinx-gdb".
This means that you need to have the name microblaze-xilinx-gdb resolved into an IP address.
This can be done by adding it to /etc/hosts.  Or you can specify the target IP address
in the DejaGNU options.  I don't recall which one off the top of my head.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang S]

Hello Maintainers:

It is finished with qemu today, it spends 13 days, the result is below,
please help check.

  With qemu:
                    === gcc Summary ===
    
    # of expected passes            83439
    # of unexpected failures        175
    # of unexpected successes       1
    # of expected failures          100
    # of unresolved testcases       349
    # of unsupported tests          1954
    /upstream/build-gcc-microblaze/gcc/xgcc  version 5.0.0 20141220 (experimental) (GCC)
  
  No qemu (originally):

                    === gcc Summary ===
    
    # of expected passes            65987
    # of unexpected failures        82
    # of unexpected successes       1
    # of expected failures          97
    # of unresolved testcases       16378
    # of unsupported tests          1810

If the result is OK, I shall start tile environments construction (
although, I guess, there is no qemu or sim for tile).

And also excuse me, during these days, gmail is broken in China, I have
to use my another mail address to send/receive emails.

Thanks.

On 12/21/14 05:45, Chen Gang wrote:
> On 12/21/2014 12:31 AM, Michael Eager wrote:
>> On 12/20/14 02:09, Chen Gang wrote:
>>> By the way, if this thread really has negative effect with other members,
>>> please warn me, I should not notify it to mailing list again, and try my
>>> best to finish it within myself.
>>
>> I appreciate your enthusiasm and perseverance in pursuing this bug.
>>
>> If the problem you are working on has changed from the mb-gcc issue,
>> change the subject.  Otherwise, keep up the good work.
>>
> 
> Thank you for your encouragement, and I should continue. At present, I
> guess my own main issues are:
> 
>  - Have no enough time resources on open source:
> 
>      sometimes need work overtime.
> 
>      need 4 hours per work day on subway between home and work office
>      (come 2 hours, go 2 hours, so total is 4 hours).
> 
>      need spend time for my child: check his homework, play with him.
>      (especially in weekend).
> 
>  - Really not familiar with gcc:
> 
>      Sometimes can find real world issues, but can not fix them in time.
> 
>      Sometimes can find coding issues, but do not know whether it can
>      cause real world issues or not (may also waste other members time
>      resources, but get no positive result).
> 
>  - Not familiar with related environments for each architectures.
> 
> So next, I should change myself for solving the issues above, firstly:
> 
>  - I shall try to spend 1-1.5 hours for reading gcc related documents (
>    e.g. "gcc info") in work day when I on subway (another time on subway
>    is for listening Holy Bible, reading news, or sleeping for a while).
> 
>  - I shall mainly forcus on finding real world issues and try to fix in
>    time. And stop finding coding issues (which may get negative effect
>    with others -- at least may waste other members time resources).
> 
>  - Still contiue for constructing all related enviroments (it is always
>    necessary) for architectures.
> 
> Welcome any ideas, suggestions or completions by any members.
> 
> Thanks.
> 

-- 
Chen Gang

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

-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 12/21/2014 12:31 AM, Michael Eager wrote:
> On 12/20/14 02:09, Chen Gang wrote:
>> By the way, if this thread really has negative effect with other members,
>> please warn me, I should not notify it to mailing list again, and try my
>> best to finish it within myself.
> 
> I appreciate your enthusiasm and perseverance in pursuing this bug.
> 
> If the problem you are working on has changed from the mb-gcc issue,
> change the subject.  Otherwise, keep up the good work.
> 

Thank you for your encouragement, and I should continue. At present, I
guess my own main issues are:

 - Have no enough time resources on open source:

     sometimes need work overtime.

     need 4 hours per work day on subway between home and work office
     (come 2 hours, go 2 hours, so total is 4 hours).

     need spend time for my child: check his homework, play with him.
     (especially in weekend).

 - Really not familiar with gcc:

     Sometimes can find real world issues, but can not fix them in time.

     Sometimes can find coding issues, but do not know whether it can
     cause real world issues or not (may also waste other members time
     resources, but get no positive result).

 - Not familiar with related environments for each architectures.

So next, I should change myself for solving the issues above, firstly:

 - I shall try to spend 1-1.5 hours for reading gcc related documents (
   e.g. "gcc info") in work day when I on subway (another time on subway
   is for listening Holy Bible, reading news, or sleeping for a while).

 - I shall mainly forcus on finding real world issues and try to fix in
   time. And stop finding coding issues (which may get negative effect
   with others -- at least may waste other members time resources).

 - Still contiue for constructing all related enviroments (it is always
   necessary) for architectures.

Welcome any ideas, suggestions or completions by any members.

Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 12/20/14 02:09, Chen Gang wrote:
> By the way, if this thread really has negative effect with other members,
> please warn me, I should not notify it to mailing list again, and try my
> best to finish it within myself.

I appreciate your enthusiasm and perseverance in pursuing this bug.

If the problem you are working on has changed from the mb-gcc issue,
change the subject.  Otherwise, keep up the good work.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

After try the latest gcc again (execuse me, during these days, I have to
do another things), all things OK, the kernel can be started by QEMU,
all related issues are fixed by other members.

I shall start the make check with qemu again (it is about 12-13 days).
I guess, this thread is almost spam thread, but I still should try my
best to finish it (then I shall try to start 'make check' for tile).

By the way, if this thread really has negative effect with other members,
please warn me, I should not notify it to mailing list again, and try my
best to finish it within myself.

Thanks.

On 11/29/2014 06:25 PM, Chen Gang wrote:
> Hello Maintainers:
> 
> After analysing, it is not kernel's issue, it is gcc issue, after let
> kernel related variable bypass this gcc issue, the kernel can start up
> successfully.
> 
> The issue is "after declaration, the __attribute_((__section__ ...))
> will be ignored". After simplification, the related shell commands are:
> 
>   [root@localhost ana]# cat test.i
>   extern int a;
>   int a __attribute__((__section__(".data..init_task"))) = 0;
>   [root@localhost ana]# /upstream/release/bin/microblaze-gchen-linux-gcc -c -o test.o test.i -save-temps
>   [root@localhost ana]# cat test.s
>   	.globl	a
>   	.bss
>   	.lcomm	a,4,4
>   	.type	a, @object
>   [root@localhost ana]# microblaze-linux-gnu-gcc -c -o test.o test.i -save-temps
>   [root@localhost ana]# cat test.s
>   	.globl	a
>   	.section	.data..init_task,"aw",@progbits
>   	.align	2
>   	.type	a,@object
>   	.size	a,4
>   a:
>   	.space	4
>   [root@localhost ana]# /upstream/release/bin/microblaze-gchen-linux-gcc -v
>   Using built-in specs.
>   COLLECT_GCC=/upstream/release/bin/microblaze-gchen-linux-gcc
>   COLLECT_LTO_WRAPPER=/upstream/release/libexec/gcc/microblaze-gchen-linux/5.0.0/lto-wrapper
>   Target: microblaze-gchen-linux
>   Configured with: ../gcc-new/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared --with-headers=/upstream/release/kernel --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic --with-sysroot=/upstream/release --prefix=/upstream/release : (reconfigured) ../gcc-new/configure --target=microblaze-gchen-linux --disable-nls --disable-threads --disable-shared --with-headers=/upstream/release/kernel --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic --with-sysroot=/upstream/release --prefix=/upstream/release target_alias=microblaze-gchen-linux --enable-languages=c,lto --no-create --no-recursion
>   Thread model: single
>   gcc version 5.0.0 20140925 (experimental) (GCC) 
> 
> 
> And it is fixed in the latest microblaze gcc version, but the latest gcc
> will cause another issue for compiling kernel. I shall try to analyse it
> within next month (2014-12-31), the related issue is:
> 
>   net/core/dev.c: In function 'register_netdevice':
>   net/core/dev.c:7285:1: internal compiler error: in verify_ssa, at tree-ssa.c:939
>    subsys_initcall(net_dev_init);
>    ^
>   0xbf77ab verify_ssa(bool, bool)
>           ../../gcc-microblaze/gcc/tree-ssa.c:939
>   0x956e6b execute_function_todo
>           ../../gcc-microblaze/gcc/passes.c:1947
>   0x95756d do_per_function
>           ../../gcc-microblaze/gcc/passes.c:1639
>   0x957683 execute_todo
>           ../../gcc-microblaze/gcc/passes.c:1997
>   Please submit a full bug report,
>   with preprocessed source if appropriate.
>   Please include the complete backtrace with any bug report.
>   See <http://gcc.gnu.org/bugs.html> for instructions.
>   make[2]: *** [net/core/dev.o] Error 1
>   [root@localhost ana]# /upstream/release-microblaze/bin/microblaze-gchen-linux-gcc -v
>   Using built-in specs.
>   COLLECT_GCC=/upstream/release-microblaze/bin/microblaze-gchen-linux-gcc
>   COLLECT_LTO_WRAPPER=/upstream/release-microblaze/libexec/gcc/microblaze-gchen-linux/5.0.0/lto-wrapper
>   Target: microblaze-gchen-linux
>   Configured with: ../gcc-microblaze/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared --with-headers=/upstream/release-microblaze/kernel --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic --with-sysroot=/upstream/release-microblaze --prefix=/upstream/release-microblaze
>   Thread model: single
>   gcc version 5.0.0 20141129 (experimental) (GCC) 
> 
> 
> After finish analysing, I shall start "make check" under microblaze qemu
> (may need about 12-13 days for testing).
> 
> Welcome any ideas, suggestions, and completions.
> 
> Thanks.
> 
> On 11/20/2014 11:33 PM, Chen Gang wrote:
>>
>> Oh, sorry, after ran more than 10 days, the qemu crashed :-(
>>
>> After checked the output log, and compare with the original log, we know
>> we have finished more than 90% test, and it is OK (no any new issues).
>> I guess the reason is I started too many other things on this machine.
>>
>> Next, I shall try to analyze "the cross compiled Linux kernel will run
>> in dead lock" issue. After finish analyzing, I shall restart the test.
>> I guess it needs 12-13 days (more than a week -- I originally expected).
>>
>> Thanks.
>>
>> On 11/9/14 21:15, Chen Gang wrote:
>>>
>>> At present, I use simplified sshd, ssh and scp (dropbear open source
>>> program) to communicate with microblaze qemu successfully, and let gcc
>>> 'make check' have real effect.
>>>
>>> It is just testing, at least after almost 10 hours, the log output is
>>> OK. For each ssh login, it will wast 10 - 20 seconds, so I guess, the
>>> "make check" may run a week!!  The recent operations is below:
>>>
>>>  - zlib (for dropbear):
>>>
>>>    export CHOST=microblaze-gchen-linux
>>>    export PATH=/upstream/release/bin:$PATH
>>>    ./configure --prefix=/upstream/release && make && make install
>>>
>>>  - dropbear (it is a simple sshd, ssh and scp):
>>>
>>>    export PATH=/upstream/release/bin:$PATH
>>>    ./configure --prefix=/upstream/release \
>>>      --host=microblaze-gchen-linux \
>>>      CC=microblaze-gchen-linux-gcc
>>>
>>>    modify /ustream/release/include/stdio.h to avoid redefining sscanf to
>>>    iso99_sscanf
>>>
>>>    link libz.a (static lib) to 'dropbear' (sshd) and 'dbclient' (ssh).
>>>    and "make scp" to generate 'scp' command.
>>>
>>>    for supporting 'none' username:
>>>
>>>      under ramfs, "echo 'none:x:0:0:none:/:/bin/sh' > ./etc/passwd"
>>>
>>>    for supporting no passwords (it is temporary fix):
>>>
>>>      modify  common-session.c: "ses.authstate.pw_passwd[0] = '\0';"
>>>
>>>    put 'dropbear', 'dbclient' and 'scp' to "./sbin" of ramfs and symbol
>>>    links to "./usr/bin" of ramfs.
>>>
>>>    for temporary fix its stable issue, need modify code to let it 'fork'
>>>    as soon as startup, and only permit one child connection each time.
>>>
>>>    usage:
>>>
>>>      in microblaze qemu:
>>>
>>>        "/sbin/dropbear -F -E -B -p 192.168.122.2:22"
>>>
>>>      in host (x86_64), use system scp and ssh is OK (without password):
>>>
>>>        ssh none@192.168.122.2 "cd /test; ./test"
>>>        scp test.c none@192.168.122.2:/test/
>>>        scp none@192.168.122.2:/test/* ./
>>>
>>>  - For dejagnu:
>>>
>>>    need `echo "192.168.122.2   microblaze-xilinx-gdb" >> /etc/hosts`
>>>    under /usr/local/share/dejagnu/*, use ssh/scp instead of rsh/rcp.
>>>      (need replace all, or will cause failure during make check).
>>>    for "/usr/local/share/dejagnu/baseboards/microblaze-xilinx-gdb.exp",
>>>    need add additional variables:
>>>
>>>      set_board_info sockethost "192.168.122.2"
>>>      set_board_info username none
>>>      set timeout 600
>>>
>>> Current left issues are:
>>>
>>>  - Linux kernel built by current upstream microblaze toolchain will be
>>>    dead lock. I shall analyze it (I guess it may be kernel self issue,
>>>    which may caused by "include/compiler-gcc5.h").
>>>
>>>  - One patch for qemu microblaze dtb file, just checking by related
>>>    members (originally I though it was kernel issue, but after
>>>    communicate with kernel members, it is more suitable to change qemu).
>>>
>>>  - One or more issues for dropbear (at least include stable issues), and
>>>    one or more issues for glibc. Sorry for I have to bypass them, since
>>>    I have no enough time resource on it.
>>>
>>>
>>> Welcome any ideas, suggestions or completions.
>>>
>>> Thanks.
>>>
>>>
>>> On 11/01/2014 01:07 AM, Chen Gang wrote:
>>>>
>>>> At present, I use telnet (without password), login to microblaze qemu
>>>> successfully!  :-)
>>>>
>>>>  - I compile busy box with the glibc in orginal 'ramfs', so get telnetd:
>>>>    use new busybox replace the old one, and add symbol link 'telnetd' to
>>>>    busybox in "/bin".
>>>>
>>>>  - configure qemu with network support (device "xlnx.xps-ethernetlite").
>>>>
>>>>    yum install libvirt
>>>>    yum install tunctl
>>>>    tunctl -b
>>>>    ip link set tap0 up
>>>>    brctl addif virbr0 tap0
>>>>    ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>>>>      -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>>>>      -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic \
>>>>      -net nic,vlan=0,model=xlnx.xps-ethernetlite,macaddr=00:16:35:AF:94:00 \
>>>>      -net tap,vlan=0,ifname=tap0,script=no,downscript=no
>>>>
>>>>  - fix a kernel bug: add "xlnx,xps-ethernetlite-2.00.b" for compatible
>>>>    with its firmware (can find it under "/sys/firmware..../compatible",
>>>>    within microblaze qemu bash environments). Related diff:
>>>>
>>>>    diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>>>    index 28dbbdc..298fad3 100644
>>>>    --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>>>    +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>>>    @@ -1236,6 +1236,7 @@ static struct of_device_id xemaclite_of_match[] = {
>>>>            { .compatible = "xlnx,opb-ethernetlite-1.01.b", },
>>>>            { .compatible = "xlnx,xps-ethernetlite-1.00.a", },
>>>>            { .compatible = "xlnx,xps-ethernetlite-2.00.a", },
>>>>    +       { .compatible = "xlnx,xps-ethernetlite-2.00.b", },
>>>>            { .compatible = "xlnx,xps-ethernetlite-2.01.a", },
>>>>            { .compatible = "xlnx,xps-ethernetlite-3.00.a", },
>>>>            { /* end of list */ },
>>>>
>>>> Next, I shall send related kernel patch for upstream kernel, and continue
>>>> for microbaze DejaGNU with microbaze qemu, and sorry again, I did not
>>>> finish it within this month.
>>>>
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> On 10/30/14 22:04, Chen Gang wrote:
>>>>> On 10/29/14 23:58, Chen Gang wrote:
>>>>>> On 10/27/14 9:42, Chen Gang wrote:
>>>>>>> On 10/27/14 2:22, Michael Eager wrote:
>>>>>>>>
>>>>>>>> Microblaze-sim provides basic instruction set architecture and memory simulation.
>>>>>>>> There is no operating system support.  (It's also quite old.  I'm not sure
>>>>>>>> which version of the MB architecture it models, but it is not recent.)
>>>>>>>>
>>>>>>>> Microblaze-sim is not a full system simulator, like QEMU.  To be able to
>>>>>>>> run a program which requires glibc, you need to be able to boot a full Linux
>>>>>>>> image on the simulator, which microblaze-sim cannot do.  QEMU models an
>>>>>>>> entire processor and can boot a Linux image.
>>>>>>>>
>>>>>>
>>>>>> At present, run upstream qemu 2.1.2 and upstream Linux kernel 3.17-rc7
>>>>>> with simple ramfs successfully. Via modify ramfs, can run hello world
>>>>>> program with static glibc (built by upstream mc_gcc), successfully.
>>>>>>
>>>>>
>>>>> After copy the ramfs' "/lib" and "/usr/lib" to outside, build the hello
>>>>> world program again with the dynamic glibc, then put it to ramfs. The
>>>>> hello world program with dynamic glibc can run correctly inside qemu :-)
>>>>>
>>>>> Next, I need focus on networking (I have found qemu related device, and
>>>>> kernel related device, and I also know, it needs telnetd in busy box).
>>>>> But sorry, it seems I can not finish within this month :-(
>>>>>
>>>>>  - I wasted much time resources on choosing qemu or sim, next I should
>>>>>    notice about it (do not waste time, again).
>>>>>
>>>>>  - and another excuse is: I have to do it in my free time (within 2.5
>>>>>    hours per day, in average). My current job is not related with it
>>>>>    (at present, it is about Global Platform Java applet for iPhone OS).
>>>>>
>>>>> Next month:
>>>>>
>>>>>  - I should finish microblaze qemu test under DejaGNU, should finish
>>>>>    within next month (2014-11-30).
>>>>>
>>>>>  - I also shall start tile cross compiling for gcc/binutils, and use it
>>>>>    to Linux kernel, and test it with qemu. I shall try to finish them
>>>>>    within 2 months (finish before 2014-12-31).
>>>>>
>>>>>  - At least, finish 1 patch for gcc, 1 patch for binutils, 1 patch for
>>>>>    qemu/kvm/xen, 3 patches for kernel, within next month (2014-11-30).
>>>>>
>>>>>
>>>>> Welcome any ideas, suggestions or completions.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>>  - For ramfs:
>>>>>>
>>>>>>    wget http://www.wiki.xilinx.com/file/view/microblaze_complete.cpio.gz/419243588/microblaze_complete.cpio.gz
>>>>>>
>>>>>>  - Related qemu command:
>>>>>>
>>>>>>    ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>>>>>>      -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>>>>>>      -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic
>>>>>>
>>>>>> Next, I shall try to let our gdb and DejaGNU work for it:
>>>>>>
>>>>>>  - How to let qemu support network and rsh (ramfs need telnetd, kernel
>>>>>>    may need related driver, and qemu related hardware need be tested).
>>>>>>
>>>>>>  - Let gdb work for it, then config DejaGNU (need we test the program
>>>>>>    with dynamic glib, it will be fail now for not match glibc version
>>>>>>    in ramfs).
>>>>>>
>>>>>>  - At last, run our test.
>>>>>>
>>>>>> It seems, still many things need trying. Welcome any ideas, suggestions,
>>>>>> and completions for it (especially for ramfs network and/or glibc, and
>>>>>> DejaGNU configuration ...).
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>>
>>>>>>> OK, thank you very much, I shall rewind to qemu, and should try my best
>>>>>>> to finish within within this month.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
> 


-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

Hello Maintainers:

After analysing, it is not kernel's issue, it is gcc issue, after let
kernel related variable bypass this gcc issue, the kernel can start up
successfully.

The issue is "after declaration, the __attribute_((__section__ ...))
will be ignored". After simplification, the related shell commands are:

  [root@localhost ana]# cat test.i
  extern int a;
  int a __attribute__((__section__(".data..init_task"))) = 0;
  [root@localhost ana]# /upstream/release/bin/microblaze-gchen-linux-gcc -c -o test.o test.i -save-temps
  [root@localhost ana]# cat test.s
  	.globl	a
  	.bss
  	.lcomm	a,4,4
  	.type	a, @object
  [root@localhost ana]# microblaze-linux-gnu-gcc -c -o test.o test.i -save-temps
  [root@localhost ana]# cat test.s
  	.globl	a
  	.section	.data..init_task,"aw",@progbits
  	.align	2
  	.type	a,@object
  	.size	a,4
  a:
  	.space	4
  [root@localhost ana]# /upstream/release/bin/microblaze-gchen-linux-gcc -v
  Using built-in specs.
  COLLECT_GCC=/upstream/release/bin/microblaze-gchen-linux-gcc
  COLLECT_LTO_WRAPPER=/upstream/release/libexec/gcc/microblaze-gchen-linux/5.0.0/lto-wrapper
  Target: microblaze-gchen-linux
  Configured with: ../gcc-new/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared --with-headers=/upstream/release/kernel --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic --with-sysroot=/upstream/release --prefix=/upstream/release : (reconfigured) ../gcc-new/configure --target=microblaze-gchen-linux --disable-nls --disable-threads --disable-shared --with-headers=/upstream/release/kernel --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic --with-sysroot=/upstream/release --prefix=/upstream/release target_alias=microblaze-gchen-linux --enable-languages=c,lto --no-create --no-recursion
  Thread model: single
  gcc version 5.0.0 20140925 (experimental) (GCC) 


And it is fixed in the latest microblaze gcc version, but the latest gcc
will cause another issue for compiling kernel. I shall try to analyse it
within next month (2014-12-31), the related issue is:

  net/core/dev.c: In function 'register_netdevice':
  net/core/dev.c:7285:1: internal compiler error: in verify_ssa, at tree-ssa.c:939
   subsys_initcall(net_dev_init);
   ^
  0xbf77ab verify_ssa(bool, bool)
          ../../gcc-microblaze/gcc/tree-ssa.c:939
  0x956e6b execute_function_todo
          ../../gcc-microblaze/gcc/passes.c:1947
  0x95756d do_per_function
          ../../gcc-microblaze/gcc/passes.c:1639
  0x957683 execute_todo
          ../../gcc-microblaze/gcc/passes.c:1997
  Please submit a full bug report,
  with preprocessed source if appropriate.
  Please include the complete backtrace with any bug report.
  See <http://gcc.gnu.org/bugs.html> for instructions.
  make[2]: *** [net/core/dev.o] Error 1
  [root@localhost ana]# /upstream/release-microblaze/bin/microblaze-gchen-linux-gcc -v
  Using built-in specs.
  COLLECT_GCC=/upstream/release-microblaze/bin/microblaze-gchen-linux-gcc
  COLLECT_LTO_WRAPPER=/upstream/release-microblaze/libexec/gcc/microblaze-gchen-linux/5.0.0/lto-wrapper
  Target: microblaze-gchen-linux
  Configured with: ../gcc-microblaze/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared --with-headers=/upstream/release-microblaze/kernel --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic --with-sysroot=/upstream/release-microblaze --prefix=/upstream/release-microblaze
  Thread model: single
  gcc version 5.0.0 20141129 (experimental) (GCC) 


After finish analysing, I shall start "make check" under microblaze qemu
(may need about 12-13 days for testing).

Welcome any ideas, suggestions, and completions.

Thanks.

On 11/20/2014 11:33 PM, Chen Gang wrote:
> 
> Oh, sorry, after ran more than 10 days, the qemu crashed :-(
> 
> After checked the output log, and compare with the original log, we know
> we have finished more than 90% test, and it is OK (no any new issues).
> I guess the reason is I started too many other things on this machine.
> 
> Next, I shall try to analyze "the cross compiled Linux kernel will run
> in dead lock" issue. After finish analyzing, I shall restart the test.
> I guess it needs 12-13 days (more than a week -- I originally expected).
> 
> Thanks.
> 
> On 11/9/14 21:15, Chen Gang wrote:
>>
>> At present, I use simplified sshd, ssh and scp (dropbear open source
>> program) to communicate with microblaze qemu successfully, and let gcc
>> 'make check' have real effect.
>>
>> It is just testing, at least after almost 10 hours, the log output is
>> OK. For each ssh login, it will wast 10 - 20 seconds, so I guess, the
>> "make check" may run a week!!  The recent operations is below:
>>
>>  - zlib (for dropbear):
>>
>>    export CHOST=microblaze-gchen-linux
>>    export PATH=/upstream/release/bin:$PATH
>>    ./configure --prefix=/upstream/release && make && make install
>>
>>  - dropbear (it is a simple sshd, ssh and scp):
>>
>>    export PATH=/upstream/release/bin:$PATH
>>    ./configure --prefix=/upstream/release \
>>      --host=microblaze-gchen-linux \
>>      CC=microblaze-gchen-linux-gcc
>>
>>    modify /ustream/release/include/stdio.h to avoid redefining sscanf to
>>    iso99_sscanf
>>
>>    link libz.a (static lib) to 'dropbear' (sshd) and 'dbclient' (ssh).
>>    and "make scp" to generate 'scp' command.
>>
>>    for supporting 'none' username:
>>
>>      under ramfs, "echo 'none:x:0:0:none:/:/bin/sh' > ./etc/passwd"
>>
>>    for supporting no passwords (it is temporary fix):
>>
>>      modify  common-session.c: "ses.authstate.pw_passwd[0] = '\0';"
>>
>>    put 'dropbear', 'dbclient' and 'scp' to "./sbin" of ramfs and symbol
>>    links to "./usr/bin" of ramfs.
>>
>>    for temporary fix its stable issue, need modify code to let it 'fork'
>>    as soon as startup, and only permit one child connection each time.
>>
>>    usage:
>>
>>      in microblaze qemu:
>>
>>        "/sbin/dropbear -F -E -B -p 192.168.122.2:22"
>>
>>      in host (x86_64), use system scp and ssh is OK (without password):
>>
>>        ssh none@192.168.122.2 "cd /test; ./test"
>>        scp test.c none@192.168.122.2:/test/
>>        scp none@192.168.122.2:/test/* ./
>>
>>  - For dejagnu:
>>
>>    need `echo "192.168.122.2   microblaze-xilinx-gdb" >> /etc/hosts`
>>    under /usr/local/share/dejagnu/*, use ssh/scp instead of rsh/rcp.
>>      (need replace all, or will cause failure during make check).
>>    for "/usr/local/share/dejagnu/baseboards/microblaze-xilinx-gdb.exp",
>>    need add additional variables:
>>
>>      set_board_info sockethost "192.168.122.2"
>>      set_board_info username none
>>      set timeout 600
>>
>> Current left issues are:
>>
>>  - Linux kernel built by current upstream microblaze toolchain will be
>>    dead lock. I shall analyze it (I guess it may be kernel self issue,
>>    which may caused by "include/compiler-gcc5.h").
>>
>>  - One patch for qemu microblaze dtb file, just checking by related
>>    members (originally I though it was kernel issue, but after
>>    communicate with kernel members, it is more suitable to change qemu).
>>
>>  - One or more issues for dropbear (at least include stable issues), and
>>    one or more issues for glibc. Sorry for I have to bypass them, since
>>    I have no enough time resource on it.
>>
>>
>> Welcome any ideas, suggestions or completions.
>>
>> Thanks.
>>
>>
>> On 11/01/2014 01:07 AM, Chen Gang wrote:
>>>
>>> At present, I use telnet (without password), login to microblaze qemu
>>> successfully!  :-)
>>>
>>>  - I compile busy box with the glibc in orginal 'ramfs', so get telnetd:
>>>    use new busybox replace the old one, and add symbol link 'telnetd' to
>>>    busybox in "/bin".
>>>
>>>  - configure qemu with network support (device "xlnx.xps-ethernetlite").
>>>
>>>    yum install libvirt
>>>    yum install tunctl
>>>    tunctl -b
>>>    ip link set tap0 up
>>>    brctl addif virbr0 tap0
>>>    ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>>>      -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>>>      -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic \
>>>      -net nic,vlan=0,model=xlnx.xps-ethernetlite,macaddr=00:16:35:AF:94:00 \
>>>      -net tap,vlan=0,ifname=tap0,script=no,downscript=no
>>>
>>>  - fix a kernel bug: add "xlnx,xps-ethernetlite-2.00.b" for compatible
>>>    with its firmware (can find it under "/sys/firmware..../compatible",
>>>    within microblaze qemu bash environments). Related diff:
>>>
>>>    diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>>    index 28dbbdc..298fad3 100644
>>>    --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>>    +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>>    @@ -1236,6 +1236,7 @@ static struct of_device_id xemaclite_of_match[] = {
>>>            { .compatible = "xlnx,opb-ethernetlite-1.01.b", },
>>>            { .compatible = "xlnx,xps-ethernetlite-1.00.a", },
>>>            { .compatible = "xlnx,xps-ethernetlite-2.00.a", },
>>>    +       { .compatible = "xlnx,xps-ethernetlite-2.00.b", },
>>>            { .compatible = "xlnx,xps-ethernetlite-2.01.a", },
>>>            { .compatible = "xlnx,xps-ethernetlite-3.00.a", },
>>>            { /* end of list */ },
>>>
>>> Next, I shall send related kernel patch for upstream kernel, and continue
>>> for microbaze DejaGNU with microbaze qemu, and sorry again, I did not
>>> finish it within this month.
>>>
>>>
>>> Thanks.
>>>
>>>
>>> On 10/30/14 22:04, Chen Gang wrote:
>>>> On 10/29/14 23:58, Chen Gang wrote:
>>>>> On 10/27/14 9:42, Chen Gang wrote:
>>>>>> On 10/27/14 2:22, Michael Eager wrote:
>>>>>>>
>>>>>>> Microblaze-sim provides basic instruction set architecture and memory simulation.
>>>>>>> There is no operating system support.  (It's also quite old.  I'm not sure
>>>>>>> which version of the MB architecture it models, but it is not recent.)
>>>>>>>
>>>>>>> Microblaze-sim is not a full system simulator, like QEMU.  To be able to
>>>>>>> run a program which requires glibc, you need to be able to boot a full Linux
>>>>>>> image on the simulator, which microblaze-sim cannot do.  QEMU models an
>>>>>>> entire processor and can boot a Linux image.
>>>>>>>
>>>>>
>>>>> At present, run upstream qemu 2.1.2 and upstream Linux kernel 3.17-rc7
>>>>> with simple ramfs successfully. Via modify ramfs, can run hello world
>>>>> program with static glibc (built by upstream mc_gcc), successfully.
>>>>>
>>>>
>>>> After copy the ramfs' "/lib" and "/usr/lib" to outside, build the hello
>>>> world program again with the dynamic glibc, then put it to ramfs. The
>>>> hello world program with dynamic glibc can run correctly inside qemu :-)
>>>>
>>>> Next, I need focus on networking (I have found qemu related device, and
>>>> kernel related device, and I also know, it needs telnetd in busy box).
>>>> But sorry, it seems I can not finish within this month :-(
>>>>
>>>>  - I wasted much time resources on choosing qemu or sim, next I should
>>>>    notice about it (do not waste time, again).
>>>>
>>>>  - and another excuse is: I have to do it in my free time (within 2.5
>>>>    hours per day, in average). My current job is not related with it
>>>>    (at present, it is about Global Platform Java applet for iPhone OS).
>>>>
>>>> Next month:
>>>>
>>>>  - I should finish microblaze qemu test under DejaGNU, should finish
>>>>    within next month (2014-11-30).
>>>>
>>>>  - I also shall start tile cross compiling for gcc/binutils, and use it
>>>>    to Linux kernel, and test it with qemu. I shall try to finish them
>>>>    within 2 months (finish before 2014-12-31).
>>>>
>>>>  - At least, finish 1 patch for gcc, 1 patch for binutils, 1 patch for
>>>>    qemu/kvm/xen, 3 patches for kernel, within next month (2014-11-30).
>>>>
>>>>
>>>> Welcome any ideas, suggestions or completions.
>>>>
>>>> Thanks.
>>>>
>>>>>  - For ramfs:
>>>>>
>>>>>    wget http://www.wiki.xilinx.com/file/view/microblaze_complete.cpio.gz/419243588/microblaze_complete.cpio.gz
>>>>>
>>>>>  - Related qemu command:
>>>>>
>>>>>    ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>>>>>      -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>>>>>      -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic
>>>>>
>>>>> Next, I shall try to let our gdb and DejaGNU work for it:
>>>>>
>>>>>  - How to let qemu support network and rsh (ramfs need telnetd, kernel
>>>>>    may need related driver, and qemu related hardware need be tested).
>>>>>
>>>>>  - Let gdb work for it, then config DejaGNU (need we test the program
>>>>>    with dynamic glib, it will be fail now for not match glibc version
>>>>>    in ramfs).
>>>>>
>>>>>  - At last, run our test.
>>>>>
>>>>> It seems, still many things need trying. Welcome any ideas, suggestions,
>>>>> and completions for it (especially for ramfs network and/or glibc, and
>>>>> DejaGNU configuration ...).
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>>>
>>>>>> OK, thank you very much, I shall rewind to qemu, and should try my best
>>>>>> to finish within within this month.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>>
>>
>>
> 


-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

Oh, sorry, after ran more than 10 days, the qemu crashed :-(

After checked the output log, and compare with the original log, we know
we have finished more than 90% test, and it is OK (no any new issues).
I guess the reason is I started too many other things on this machine.

Next, I shall try to analyze "the cross compiled Linux kernel will run
in dead lock" issue. After finish analyzing, I shall restart the test.
I guess it needs 12-13 days (more than a week -- I originally expected).

Thanks.

On 11/9/14 21:15, Chen Gang wrote:
> 
> At present, I use simplified sshd, ssh and scp (dropbear open source
> program) to communicate with microblaze qemu successfully, and let gcc
> 'make check' have real effect.
> 
> It is just testing, at least after almost 10 hours, the log output is
> OK. For each ssh login, it will wast 10 - 20 seconds, so I guess, the
> "make check" may run a week!!  The recent operations is below:
> 
>  - zlib (for dropbear):
> 
>    export CHOST=microblaze-gchen-linux
>    export PATH=/upstream/release/bin:$PATH
>    ./configure --prefix=/upstream/release && make && make install
> 
>  - dropbear (it is a simple sshd, ssh and scp):
> 
>    export PATH=/upstream/release/bin:$PATH
>    ./configure --prefix=/upstream/release \
>      --host=microblaze-gchen-linux \
>      CC=microblaze-gchen-linux-gcc
> 
>    modify /ustream/release/include/stdio.h to avoid redefining sscanf to
>    iso99_sscanf
> 
>    link libz.a (static lib) to 'dropbear' (sshd) and 'dbclient' (ssh).
>    and "make scp" to generate 'scp' command.
> 
>    for supporting 'none' username:
> 
>      under ramfs, "echo 'none:x:0:0:none:/:/bin/sh' > ./etc/passwd"
> 
>    for supporting no passwords (it is temporary fix):
> 
>      modify  common-session.c: "ses.authstate.pw_passwd[0] = '\0';"
> 
>    put 'dropbear', 'dbclient' and 'scp' to "./sbin" of ramfs and symbol
>    links to "./usr/bin" of ramfs.
> 
>    for temporary fix its stable issue, need modify code to let it 'fork'
>    as soon as startup, and only permit one child connection each time.
> 
>    usage:
> 
>      in microblaze qemu:
> 
>        "/sbin/dropbear -F -E -B -p 192.168.122.2:22"
> 
>      in host (x86_64), use system scp and ssh is OK (without password):
> 
>        ssh none@192.168.122.2 "cd /test; ./test"
>        scp test.c none@192.168.122.2:/test/
>        scp none@192.168.122.2:/test/* ./
> 
>  - For dejagnu:
> 
>    need `echo "192.168.122.2   microblaze-xilinx-gdb" >> /etc/hosts`
>    under /usr/local/share/dejagnu/*, use ssh/scp instead of rsh/rcp.
>      (need replace all, or will cause failure during make check).
>    for "/usr/local/share/dejagnu/baseboards/microblaze-xilinx-gdb.exp",
>    need add additional variables:
> 
>      set_board_info sockethost "192.168.122.2"
>      set_board_info username none
>      set timeout 600
> 
> Current left issues are:
> 
>  - Linux kernel built by current upstream microblaze toolchain will be
>    dead lock. I shall analyze it (I guess it may be kernel self issue,
>    which may caused by "include/compiler-gcc5.h").
> 
>  - One patch for qemu microblaze dtb file, just checking by related
>    members (originally I though it was kernel issue, but after
>    communicate with kernel members, it is more suitable to change qemu).
> 
>  - One or more issues for dropbear (at least include stable issues), and
>    one or more issues for glibc. Sorry for I have to bypass them, since
>    I have no enough time resource on it.
> 
> 
> Welcome any ideas, suggestions or completions.
> 
> Thanks.
> 
> 
> On 11/01/2014 01:07 AM, Chen Gang wrote:
>>
>> At present, I use telnet (without password), login to microblaze qemu
>> successfully!  :-)
>>
>>  - I compile busy box with the glibc in orginal 'ramfs', so get telnetd:
>>    use new busybox replace the old one, and add symbol link 'telnetd' to
>>    busybox in "/bin".
>>
>>  - configure qemu with network support (device "xlnx.xps-ethernetlite").
>>
>>    yum install libvirt
>>    yum install tunctl
>>    tunctl -b
>>    ip link set tap0 up
>>    brctl addif virbr0 tap0
>>    ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>>      -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>>      -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic \
>>      -net nic,vlan=0,model=xlnx.xps-ethernetlite,macaddr=00:16:35:AF:94:00 \
>>      -net tap,vlan=0,ifname=tap0,script=no,downscript=no
>>
>>  - fix a kernel bug: add "xlnx,xps-ethernetlite-2.00.b" for compatible
>>    with its firmware (can find it under "/sys/firmware..../compatible",
>>    within microblaze qemu bash environments). Related diff:
>>
>>    diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>    index 28dbbdc..298fad3 100644
>>    --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>    +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>    @@ -1236,6 +1236,7 @@ static struct of_device_id xemaclite_of_match[] = {
>>            { .compatible = "xlnx,opb-ethernetlite-1.01.b", },
>>            { .compatible = "xlnx,xps-ethernetlite-1.00.a", },
>>            { .compatible = "xlnx,xps-ethernetlite-2.00.a", },
>>    +       { .compatible = "xlnx,xps-ethernetlite-2.00.b", },
>>            { .compatible = "xlnx,xps-ethernetlite-2.01.a", },
>>            { .compatible = "xlnx,xps-ethernetlite-3.00.a", },
>>            { /* end of list */ },
>>
>> Next, I shall send related kernel patch for upstream kernel, and continue
>> for microbaze DejaGNU with microbaze qemu, and sorry again, I did not
>> finish it within this month.
>>
>>
>> Thanks.
>>
>>
>> On 10/30/14 22:04, Chen Gang wrote:
>>> On 10/29/14 23:58, Chen Gang wrote:
>>>> On 10/27/14 9:42, Chen Gang wrote:
>>>>> On 10/27/14 2:22, Michael Eager wrote:
>>>>>>
>>>>>> Microblaze-sim provides basic instruction set architecture and memory simulation.
>>>>>> There is no operating system support.  (It's also quite old.  I'm not sure
>>>>>> which version of the MB architecture it models, but it is not recent.)
>>>>>>
>>>>>> Microblaze-sim is not a full system simulator, like QEMU.  To be able to
>>>>>> run a program which requires glibc, you need to be able to boot a full Linux
>>>>>> image on the simulator, which microblaze-sim cannot do.  QEMU models an
>>>>>> entire processor and can boot a Linux image.
>>>>>>
>>>>
>>>> At present, run upstream qemu 2.1.2 and upstream Linux kernel 3.17-rc7
>>>> with simple ramfs successfully. Via modify ramfs, can run hello world
>>>> program with static glibc (built by upstream mc_gcc), successfully.
>>>>
>>>
>>> After copy the ramfs' "/lib" and "/usr/lib" to outside, build the hello
>>> world program again with the dynamic glibc, then put it to ramfs. The
>>> hello world program with dynamic glibc can run correctly inside qemu :-)
>>>
>>> Next, I need focus on networking (I have found qemu related device, and
>>> kernel related device, and I also know, it needs telnetd in busy box).
>>> But sorry, it seems I can not finish within this month :-(
>>>
>>>  - I wasted much time resources on choosing qemu or sim, next I should
>>>    notice about it (do not waste time, again).
>>>
>>>  - and another excuse is: I have to do it in my free time (within 2.5
>>>    hours per day, in average). My current job is not related with it
>>>    (at present, it is about Global Platform Java applet for iPhone OS).
>>>
>>> Next month:
>>>
>>>  - I should finish microblaze qemu test under DejaGNU, should finish
>>>    within next month (2014-11-30).
>>>
>>>  - I also shall start tile cross compiling for gcc/binutils, and use it
>>>    to Linux kernel, and test it with qemu. I shall try to finish them
>>>    within 2 months (finish before 2014-12-31).
>>>
>>>  - At least, finish 1 patch for gcc, 1 patch for binutils, 1 patch for
>>>    qemu/kvm/xen, 3 patches for kernel, within next month (2014-11-30).
>>>
>>>
>>> Welcome any ideas, suggestions or completions.
>>>
>>> Thanks.
>>>
>>>>  - For ramfs:
>>>>
>>>>    wget http://www.wiki.xilinx.com/file/view/microblaze_complete.cpio.gz/419243588/microblaze_complete.cpio.gz
>>>>
>>>>  - Related qemu command:
>>>>
>>>>    ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>>>>      -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>>>>      -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic
>>>>
>>>> Next, I shall try to let our gdb and DejaGNU work for it:
>>>>
>>>>  - How to let qemu support network and rsh (ramfs need telnetd, kernel
>>>>    may need related driver, and qemu related hardware need be tested).
>>>>
>>>>  - Let gdb work for it, then config DejaGNU (need we test the program
>>>>    with dynamic glib, it will be fail now for not match glibc version
>>>>    in ramfs).
>>>>
>>>>  - At last, run our test.
>>>>
>>>> It seems, still many things need trying. Welcome any ideas, suggestions,
>>>> and completions for it (especially for ramfs network and/or glibc, and
>>>> DejaGNU configuration ...).
>>>>
>>>>
>>>> Thanks.
>>>>
>>>>>
>>>>> OK, thank you very much, I shall rewind to qemu, and should try my best
>>>>> to finish within within this month.
>>>>>
>>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>
>>
> 
> 

-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

At present, I use simplified sshd, ssh and scp (dropbear open source
program) to communicate with microblaze qemu successfully, and let gcc
'make check' have real effect.

It is just testing, at least after almost 10 hours, the log output is
OK. For each ssh login, it will wast 10 - 20 seconds, so I guess, the
"make check" may run a week!!  The recent operations is below:

 - zlib (for dropbear):

   export CHOST=microblaze-gchen-linux
   export PATH=/upstream/release/bin:$PATH
   ./configure --prefix=/upstream/release && make && make install

 - dropbear (it is a simple sshd, ssh and scp):

   export PATH=/upstream/release/bin:$PATH
   ./configure --prefix=/upstream/release \
     --host=microblaze-gchen-linux \
     CC=microblaze-gchen-linux-gcc

   modify /ustream/release/include/stdio.h to avoid redefining sscanf to
   iso99_sscanf

   link libz.a (static lib) to 'dropbear' (sshd) and 'dbclient' (ssh).
   and "make scp" to generate 'scp' command.

   for supporting 'none' username:

     under ramfs, "echo 'none:x:0:0:none:/:/bin/sh' > ./etc/passwd"

   for supporting no passwords (it is temporary fix):

     modify  common-session.c: "ses.authstate.pw_passwd[0] = '\0';"

   put 'dropbear', 'dbclient' and 'scp' to "./sbin" of ramfs and symbol
   links to "./usr/bin" of ramfs.

   for temporary fix its stable issue, need modify code to let it 'fork'
   as soon as startup, and only permit one child connection each time.

   usage:

     in microblaze qemu:

       "/sbin/dropbear -F -E -B -p 192.168.122.2:22"

     in host (x86_64), use system scp and ssh is OK (without password):

       ssh none@192.168.122.2 "cd /test; ./test"
       scp test.c none@192.168.122.2:/test/
       scp none@192.168.122.2:/test/* ./

 - For dejagnu:

   need `echo "192.168.122.2   microblaze-xilinx-gdb" >> /etc/hosts`
   under /usr/local/share/dejagnu/*, use ssh/scp instead of rsh/rcp.
     (need replace all, or will cause failure during make check).
   for "/usr/local/share/dejagnu/baseboards/microblaze-xilinx-gdb.exp",
   need add additional variables:

     set_board_info sockethost "192.168.122.2"
     set_board_info username none
     set timeout 600

Current left issues are:

 - Linux kernel built by current upstream microblaze toolchain will be
   dead lock. I shall analyze it (I guess it may be kernel self issue,
   which may caused by "include/compiler-gcc5.h").

 - One patch for qemu microblaze dtb file, just checking by related
   members (originally I though it was kernel issue, but after
   communicate with kernel members, it is more suitable to change qemu).

 - One or more issues for dropbear (at least include stable issues), and
   one or more issues for glibc. Sorry for I have to bypass them, since
   I have no enough time resource on it.


Welcome any ideas, suggestions or completions.

Thanks.


On 11/01/2014 01:07 AM, Chen Gang wrote:
> 
> At present, I use telnet (without password), login to microblaze qemu
> successfully!  :-)
> 
>  - I compile busy box with the glibc in orginal 'ramfs', so get telnetd:
>    use new busybox replace the old one, and add symbol link 'telnetd' to
>    busybox in "/bin".
> 
>  - configure qemu with network support (device "xlnx.xps-ethernetlite").
> 
>    yum install libvirt
>    yum install tunctl
>    tunctl -b
>    ip link set tap0 up
>    brctl addif virbr0 tap0
>    ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>      -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>      -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic \
>      -net nic,vlan=0,model=xlnx.xps-ethernetlite,macaddr=00:16:35:AF:94:00 \
>      -net tap,vlan=0,ifname=tap0,script=no,downscript=no
> 
>  - fix a kernel bug: add "xlnx,xps-ethernetlite-2.00.b" for compatible
>    with its firmware (can find it under "/sys/firmware..../compatible",
>    within microblaze qemu bash environments). Related diff:
> 
>    diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>    index 28dbbdc..298fad3 100644
>    --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>    +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>    @@ -1236,6 +1236,7 @@ static struct of_device_id xemaclite_of_match[] = {
>            { .compatible = "xlnx,opb-ethernetlite-1.01.b", },
>            { .compatible = "xlnx,xps-ethernetlite-1.00.a", },
>            { .compatible = "xlnx,xps-ethernetlite-2.00.a", },
>    +       { .compatible = "xlnx,xps-ethernetlite-2.00.b", },
>            { .compatible = "xlnx,xps-ethernetlite-2.01.a", },
>            { .compatible = "xlnx,xps-ethernetlite-3.00.a", },
>            { /* end of list */ },
> 
> Next, I shall send related kernel patch for upstream kernel, and continue
> for microbaze DejaGNU with microbaze qemu, and sorry again, I did not
> finish it within this month.
> 
> 
> Thanks.
> 
> 
> On 10/30/14 22:04, Chen Gang wrote:
>> On 10/29/14 23:58, Chen Gang wrote:
>>> On 10/27/14 9:42, Chen Gang wrote:
>>>> On 10/27/14 2:22, Michael Eager wrote:
>>>>>
>>>>> Microblaze-sim provides basic instruction set architecture and memory simulation.
>>>>> There is no operating system support.  (It's also quite old.  I'm not sure
>>>>> which version of the MB architecture it models, but it is not recent.)
>>>>>
>>>>> Microblaze-sim is not a full system simulator, like QEMU.  To be able to
>>>>> run a program which requires glibc, you need to be able to boot a full Linux
>>>>> image on the simulator, which microblaze-sim cannot do.  QEMU models an
>>>>> entire processor and can boot a Linux image.
>>>>>
>>>
>>> At present, run upstream qemu 2.1.2 and upstream Linux kernel 3.17-rc7
>>> with simple ramfs successfully. Via modify ramfs, can run hello world
>>> program with static glibc (built by upstream mc_gcc), successfully.
>>>
>>
>> After copy the ramfs' "/lib" and "/usr/lib" to outside, build the hello
>> world program again with the dynamic glibc, then put it to ramfs. The
>> hello world program with dynamic glibc can run correctly inside qemu :-)
>>
>> Next, I need focus on networking (I have found qemu related device, and
>> kernel related device, and I also know, it needs telnetd in busy box).
>> But sorry, it seems I can not finish within this month :-(
>>
>>  - I wasted much time resources on choosing qemu or sim, next I should
>>    notice about it (do not waste time, again).
>>
>>  - and another excuse is: I have to do it in my free time (within 2.5
>>    hours per day, in average). My current job is not related with it
>>    (at present, it is about Global Platform Java applet for iPhone OS).
>>
>> Next month:
>>
>>  - I should finish microblaze qemu test under DejaGNU, should finish
>>    within next month (2014-11-30).
>>
>>  - I also shall start tile cross compiling for gcc/binutils, and use it
>>    to Linux kernel, and test it with qemu. I shall try to finish them
>>    within 2 months (finish before 2014-12-31).
>>
>>  - At least, finish 1 patch for gcc, 1 patch for binutils, 1 patch for
>>    qemu/kvm/xen, 3 patches for kernel, within next month (2014-11-30).
>>
>>
>> Welcome any ideas, suggestions or completions.
>>
>> Thanks.
>>
>>>  - For ramfs:
>>>
>>>    wget http://www.wiki.xilinx.com/file/view/microblaze_complete.cpio.gz/419243588/microblaze_complete.cpio.gz
>>>
>>>  - Related qemu command:
>>>
>>>    ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>>>      -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>>>      -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic
>>>
>>> Next, I shall try to let our gdb and DejaGNU work for it:
>>>
>>>  - How to let qemu support network and rsh (ramfs need telnetd, kernel
>>>    may need related driver, and qemu related hardware need be tested).
>>>
>>>  - Let gdb work for it, then config DejaGNU (need we test the program
>>>    with dynamic glib, it will be fail now for not match glibc version
>>>    in ramfs).
>>>
>>>  - At last, run our test.
>>>
>>> It seems, still many things need trying. Welcome any ideas, suggestions,
>>> and completions for it (especially for ramfs network and/or glibc, and
>>> DejaGNU configuration ...).
>>>
>>>
>>> Thanks.
>>>
>>>>
>>>> OK, thank you very much, I shall rewind to qemu, and should try my best
>>>> to finish within within this month.
>>>>
>>>>
>>>
>>>
>>> Thanks
>>>
>>
> 


-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

At present, I use telnet (without password), login to microblaze qemu
successfully!  :-)

 - I compile busy box with the glibc in orginal 'ramfs', so get telnetd:
   use new busybox replace the old one, and add symbol link 'telnetd' to
   busybox in "/bin".

 - configure qemu with network support (device "xlnx.xps-ethernetlite").

   yum install libvirt
   yum install tunctl
   tunctl -b
   ip link set tap0 up
   brctl addif virbr0 tap0
   ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
     -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
     -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic \
     -net nic,vlan=0,model=xlnx.xps-ethernetlite,macaddr=00:16:35:AF:94:00 \
     -net tap,vlan=0,ifname=tap0,script=no,downscript=no

 - fix a kernel bug: add "xlnx,xps-ethernetlite-2.00.b" for compatible
   with its firmware (can find it under "/sys/firmware..../compatible",
   within microblaze qemu bash environments). Related diff:

   diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
   index 28dbbdc..298fad3 100644
   --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
   +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
   @@ -1236,6 +1236,7 @@ static struct of_device_id xemaclite_of_match[] = {
           { .compatible = "xlnx,opb-ethernetlite-1.01.b", },
           { .compatible = "xlnx,xps-ethernetlite-1.00.a", },
           { .compatible = "xlnx,xps-ethernetlite-2.00.a", },
   +       { .compatible = "xlnx,xps-ethernetlite-2.00.b", },
           { .compatible = "xlnx,xps-ethernetlite-2.01.a", },
           { .compatible = "xlnx,xps-ethernetlite-3.00.a", },
           { /* end of list */ },

Next, I shall send related kernel patch for upstream kernel, and continue
for microbaze DejaGNU with microbaze qemu, and sorry again, I did not
finish it within this month.


Thanks.


On 10/30/14 22:04, Chen Gang wrote:
> On 10/29/14 23:58, Chen Gang wrote:
>> On 10/27/14 9:42, Chen Gang wrote:
>>> On 10/27/14 2:22, Michael Eager wrote:
>>>>
>>>> Microblaze-sim provides basic instruction set architecture and memory simulation.
>>>> There is no operating system support.  (It's also quite old.  I'm not sure
>>>> which version of the MB architecture it models, but it is not recent.)
>>>>
>>>> Microblaze-sim is not a full system simulator, like QEMU.  To be able to
>>>> run a program which requires glibc, you need to be able to boot a full Linux
>>>> image on the simulator, which microblaze-sim cannot do.  QEMU models an
>>>> entire processor and can boot a Linux image.
>>>>
>>
>> At present, run upstream qemu 2.1.2 and upstream Linux kernel 3.17-rc7
>> with simple ramfs successfully. Via modify ramfs, can run hello world
>> program with static glibc (built by upstream mc_gcc), successfully.
>>
> 
> After copy the ramfs' "/lib" and "/usr/lib" to outside, build the hello
> world program again with the dynamic glibc, then put it to ramfs. The
> hello world program with dynamic glibc can run correctly inside qemu :-)
> 
> Next, I need focus on networking (I have found qemu related device, and
> kernel related device, and I also know, it needs telnetd in busy box).
> But sorry, it seems I can not finish within this month :-(
> 
>  - I wasted much time resources on choosing qemu or sim, next I should
>    notice about it (do not waste time, again).
> 
>  - and another excuse is: I have to do it in my free time (within 2.5
>    hours per day, in average). My current job is not related with it
>    (at present, it is about Global Platform Java applet for iPhone OS).
> 
> Next month:
> 
>  - I should finish microblaze qemu test under DejaGNU, should finish
>    within next month (2014-11-30).
> 
>  - I also shall start tile cross compiling for gcc/binutils, and use it
>    to Linux kernel, and test it with qemu. I shall try to finish them
>    within 2 months (finish before 2014-12-31).
> 
>  - At least, finish 1 patch for gcc, 1 patch for binutils, 1 patch for
>    qemu/kvm/xen, 3 patches for kernel, within next month (2014-11-30).
> 
> 
> Welcome any ideas, suggestions or completions.
> 
> Thanks.
> 
>>  - For ramfs:
>>
>>    wget http://www.wiki.xilinx.com/file/view/microblaze_complete.cpio.gz/419243588/microblaze_complete.cpio.gz
>>
>>  - Related qemu command:
>>
>>    ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>>      -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>>      -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic
>>
>> Next, I shall try to let our gdb and DejaGNU work for it:
>>
>>  - How to let qemu support network and rsh (ramfs need telnetd, kernel
>>    may need related driver, and qemu related hardware need be tested).
>>
>>  - Let gdb work for it, then config DejaGNU (need we test the program
>>    with dynamic glib, it will be fail now for not match glibc version
>>    in ramfs).
>>
>>  - At last, run our test.
>>
>> It seems, still many things need trying. Welcome any ideas, suggestions,
>> and completions for it (especially for ramfs network and/or glibc, and
>> DejaGNU configuration ...).
>>
>>
>> Thanks.
>>
>>>
>>> OK, thank you very much, I shall rewind to qemu, and should try my best
>>> to finish within within this month.
>>>
>>>
>>
>>
>> Thanks
>>
> 

-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/29/14 23:58, Chen Gang wrote:
> On 10/27/14 9:42, Chen Gang wrote:
>> On 10/27/14 2:22, Michael Eager wrote:
>>>
>>> Microblaze-sim provides basic instruction set architecture and memory simulation.
>>> There is no operating system support.  (It's also quite old.  I'm not sure
>>> which version of the MB architecture it models, but it is not recent.)
>>>
>>> Microblaze-sim is not a full system simulator, like QEMU.  To be able to
>>> run a program which requires glibc, you need to be able to boot a full Linux
>>> image on the simulator, which microblaze-sim cannot do.  QEMU models an
>>> entire processor and can boot a Linux image.
>>>
> 
> At present, run upstream qemu 2.1.2 and upstream Linux kernel 3.17-rc7
> with simple ramfs successfully. Via modify ramfs, can run hello world
> program with static glibc (built by upstream mc_gcc), successfully.
> 

After copy the ramfs' "/lib" and "/usr/lib" to outside, build the hello
world program again with the dynamic glibc, then put it to ramfs. The
hello world program with dynamic glibc can run correctly inside qemu :-)

Next, I need focus on networking (I have found qemu related device, and
kernel related device, and I also know, it needs telnetd in busy box).
But sorry, it seems I can not finish within this month :-(

 - I wasted much time resources on choosing qemu or sim, next I should
   notice about it (do not waste time, again).

 - and another excuse is: I have to do it in my free time (within 2.5
   hours per day, in average). My current job is not related with it
   (at present, it is about Global Platform Java applet for iPhone OS).

Next month:

 - I should finish microblaze qemu test under DejaGNU, should finish
   within next month (2014-11-30).

 - I also shall start tile cross compiling for gcc/binutils, and use it
   to Linux kernel, and test it with qemu. I shall try to finish them
   within 2 months (finish before 2014-12-31).

 - At least, finish 1 patch for gcc, 1 patch for binutils, 1 patch for
   qemu/kvm/xen, 3 patches for kernel, within next month (2014-11-30).


Welcome any ideas, suggestions or completions.

Thanks.

>  - For ramfs:
> 
>    wget http://www.wiki.xilinx.com/file/view/microblaze_complete.cpio.gz/419243588/microblaze_complete.cpio.gz
> 
>  - Related qemu command:
> 
>    ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>      -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>      -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic
> 
> Next, I shall try to let our gdb and DejaGNU work for it:
> 
>  - How to let qemu support network and rsh (ramfs need telnetd, kernel
>    may need related driver, and qemu related hardware need be tested).
> 
>  - Let gdb work for it, then config DejaGNU (need we test the program
>    with dynamic glib, it will be fail now for not match glibc version
>    in ramfs).
> 
>  - At last, run our test.
> 
> It seems, still many things need trying. Welcome any ideas, suggestions,
> and completions for it (especially for ramfs network and/or glibc, and
> DejaGNU configuration ...).
> 
> 
> Thanks.
> 
>>
>> OK, thank you very much, I shall rewind to qemu, and should try my best
>> to finish within within this month.
>>
>>
> 
> 
> Thanks
> 

-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/27/14 9:42, Chen Gang wrote:
> On 10/27/14 2:22, Michael Eager wrote:
>>
>> Microblaze-sim provides basic instruction set architecture and memory simulation.
>> There is no operating system support.  (It's also quite old.  I'm not sure
>> which version of the MB architecture it models, but it is not recent.)
>>
>> Microblaze-sim is not a full system simulator, like QEMU.  To be able to
>> run a program which requires glibc, you need to be able to boot a full Linux
>> image on the simulator, which microblaze-sim cannot do.  QEMU models an
>> entire processor and can boot a Linux image.
>>

At present, run upstream qemu 2.1.2 and upstream Linux kernel 3.17-rc7
with simple ramfs successfully. Via modify ramfs, can run hello world
program with static glibc (built by upstream mc_gcc), successfully.

 - For ramfs:

   wget http://www.wiki.xilinx.com/file/view/microblaze_complete.cpio.gz/419243588/microblaze_complete.cpio.gz

 - Related qemu command:

   ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
     -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
     -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic

Next, I shall try to let our gdb and DejaGNU work for it:

 - How to let qemu support network and rsh (ramfs need telnetd, kernel
   may need related driver, and qemu related hardware need be tested).

 - Let gdb work for it, then config DejaGNU (need we test the program
   with dynamic glib, it will be fail now for not match glibc version
   in ramfs).

 - At last, run our test.

It seems, still many things need trying. Welcome any ideas, suggestions,
and completions for it (especially for ramfs network and/or glibc, and
DejaGNU configuration ...).


Thanks.

> 
> OK, thank you very much, I shall rewind to qemu, and should try my best
> to finish within within this month.
> 
> 


Thanks
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/27/14 2:22, Michael Eager wrote:
> On 10/26/14 03:36, Chen Gang wrote:
>> On 10/22/2014 09:34 AM, Chen Gang wrote:
>>>
>>>>>
>>>>> Yes, if you want to test on a target, you will need a target.  You can either have a simulator (see binutils and sim/* for an example of how to write one) or target hardware in some form.
>>>>>
>>
>> After tried 'sim', I found the root cause is microblaze sim does not
>> support '--sysroot', which is the environments for shared libraries and
>> system calls (need load microblaze kernel).
>>
>>   - microblaze can successfully execute simple programs which has no
>>     glibc and no system call.
>>
>>   - In upstream master branch of binutils, for microblaze sim, it has no
>>     related testsuite for sim in binutils, neither support '--sysroot',
>>     neither support function stack, startup parameters, and environments.
>>
>>   - After hard code the default stack in sim, it can start the '-static'
>>     program with glibc, but stop at uname() which will use system call.
>>
>> So I want to consult: at present, can we let microblaze sim run 'normal'
>> programs (have glibc, and use system call)?
> 
> Microblaze-sim provides basic instruction set architecture and memory simulation.
> There is no operating system support.  (It's also quite old.  I'm not sure
> which version of the MB architecture it models, but it is not recent.)
> 
> Microblaze-sim is not a full system simulator, like QEMU.  To be able to
> run a program which requires glibc, you need to be able to boot a full Linux
> image on the simulator, which microblaze-sim cannot do.  QEMU models an
> entire processor and can boot a Linux image.
> 

OK, thank you very much, I shall rewind to qemu, and should try my best
to finish within within this month.


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 10/26/14 03:36, Chen Gang wrote:
> On 10/22/2014 09:34 AM, Chen Gang wrote:
>>
>>>>
>>>> Yes, if you want to test on a target, you will need a target.  You can either have a simulator (see binutils and sim/* for an example of how to write one) or target hardware in some form.
>>>>
>
> After tried 'sim', I found the root cause is microblaze sim does not
> support '--sysroot', which is the environments for shared libraries and
> system calls (need load microblaze kernel).
>
>   - microblaze can successfully execute simple programs which has no
>     glibc and no system call.
>
>   - In upstream master branch of binutils, for microblaze sim, it has no
>     related testsuite for sim in binutils, neither support '--sysroot',
>     neither support function stack, startup parameters, and environments.
>
>   - After hard code the default stack in sim, it can start the '-static'
>     program with glibc, but stop at uname() which will use system call.
>
> So I want to consult: at present, can we let microblaze sim run 'normal'
> programs (have glibc, and use system call)?

Microblaze-sim provides basic instruction set architecture and memory simulation.
There is no operating system support.  (It's also quite old.  I'm not sure
which version of the MB architecture it models, but it is not recent.)

Microblaze-sim is not a full system simulator, like QEMU.  To be able to
run a program which requires glibc, you need to be able to boot a full Linux
image on the simulator, which microblaze-sim cannot do.  QEMU models an
entire processor and can boot a Linux image.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/22/2014 09:34 AM, Chen Gang wrote:
> 
>>>
>>> Yes, if you want to test on a target, you will need a target.  You can either have a simulator (see binutils and sim/* for an example of how to write one) or target hardware in some form.
>>>

After tried 'sim', I found the root cause is microblaze sim does not
support '--sysroot', which is the environments for shared libraries and
system calls (need load microblaze kernel).

 - microblaze can successfully execute simple programs which has no
   glibc and no system call.

 - In upstream master branch of binutils, for microblaze sim, it has no
   related testsuite for sim in binutils, neither support '--sysroot',
   neither support function stack, startup parameters, and environments.

 - After hard code the default stack in sim, it can start the '-static'
   program with glibc, but stop at uname() which will use system call.

So I want to consult: at present, can we let microblaze sim run 'normal'
programs (have glibc, and use system call)?


If it does not support, I have to rewind to qemu. If it really happens,
it seems I can not finish "gcc testsuite with target" within this month.
(although I have several excuses) :-(

Thanks.

> 
> I will continue sim, and should try to finish within 2014-10-31. Sorry,
> my other things which related open source maybe be delayed (maybe can
> not finish within this month, if happens, need finish within next month).
> 
>>
>> After trying sim, for me, it is really useful way for test, although I
>> also met issues:
>>
>> For a hello world C program, microblaze gcc succeeded building, gdb can
>> load and display the source code, and disassembe code successfully, but
>> sim reported failure, the related issue is below:
>>
>>   [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-run ./test
>>   Loading section .interp, size 0xd vma 0x100000f4
>>   Loading section .note.ABI-tag, size 0x20 vma 0x10000104
>>   Loading section .hash, size 0x24 vma 0x10000124
>>   Loading section .dynsym, size 0x40 vma 0x10000148
>>   Loading section .dynstr, size 0x3c vma 0x10000188
>>   Loading section .gnu.version, size 0x8 vma 0x100001c4
>>   Loading section .gnu.version_r, size 0x20 vma 0x100001cc
>>   Loading section .rela.dyn, size 0x24 vma 0x100001ec
>>   Loading section .rela.plt, size 0x24 vma 0x10000210
>>   Loading section .init, size 0x58 vma 0x10000234
>>   Loading section .plt, size 0x44 vma 0x1000028c
>>   Loading section .text, size 0x3d0 vma 0x100002d0
>>   Loading section .fini, size 0x34 vma 0x100006a0
>>   Loading section .rodata, size 0x12 vma 0x100006d4
>>   Loading section .eh_frame, size 0x4 vma 0x100006e8
>>   Loading section .ctors, size 0x8 vma 0x100016ec
>>   Loading section .dtors, size 0x8 vma 0x100016f4
>>   Loading section .jcr, size 0x4 vma 0x100016fc
>>   Loading section .dynamic, size 0xd0 vma 0x10001700
>>   Loading section .got, size 0xc vma 0x100017d0
>>   Loading section .got.plt, size 0x18 vma 0x100017dc
>>   Loading section .data, size 0x10 vma 0x100017f4
>>   Start address 0x100002d0
>>   Transfer rate: 14424 bits in <1 sec.
>>   ERROR: Unknown opcode
>>   program stopped with signal 4.
>>
>> For me, I guess it is sim's issue, and I shall try to fix it in the next
>> month, so sorry, I can not finish emulator for microblaze within this
>> month. :-(
>>
>>
>> Welcome any ideas, suggestions or completions.
>>
>> Thanks.
>>
> 


-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/21/14 22:55, Chen Gang wrote:
> On 09/25/2014 08:12 AM, Chen Gang wrote:
>> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on Qemu, and try to make patches for it).
>>
> 
> Excuse me, after tried upstream qemu, it cann't run microblaze correctly,
> even for Xilinx qemu branch, I cann't run correctly either. I tried to
> consult related members in qemu mailing list, but got no result.
> 
> After compared upstream branch and Xilinx branch, I am sure upstream
> microblaze qemu is lack of several related main features about
> microblaze.
> 
> For qemu, I have to only focus on upstream, and try bug fix patches, new
> features and version merging are out of my current border, so sorry, I
> have to stop trying qemu for microblaze gcc test, at present.
> 

Oh, sorry, after communicate with the qemu members, there are multiple
upstream branches for qemu, so I can only say: for upstream develop
master qemu, it does not support microblaze main features.

There are several upstream qemu distributions may support microblaze.  I
do not mainly focus on only using qemu, so I will stop qemu and try sim.

>>> So I guess the root cause is: I only use cross-compiling environments
>>> under fedora x86_64, no any real or virtual target for test.
>>
>> Yes, if you want to test on a target, you will need a target.  You can either have a simulator (see binutils and sim/* for an example of how to write one) or target hardware in some form.
>>

I will continue sim, and should try to finish within 2014-10-31. Sorry,
my other things which related open source maybe be delayed (maybe can
not finish within this month, if happens, need finish within next month).

> 
> After trying sim, for me, it is really useful way for test, although I
> also met issues:
> 
> For a hello world C program, microblaze gcc succeeded building, gdb can
> load and display the source code, and disassembe code successfully, but
> sim reported failure, the related issue is below:
> 
>   [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-run ./test
>   Loading section .interp, size 0xd vma 0x100000f4
>   Loading section .note.ABI-tag, size 0x20 vma 0x10000104
>   Loading section .hash, size 0x24 vma 0x10000124
>   Loading section .dynsym, size 0x40 vma 0x10000148
>   Loading section .dynstr, size 0x3c vma 0x10000188
>   Loading section .gnu.version, size 0x8 vma 0x100001c4
>   Loading section .gnu.version_r, size 0x20 vma 0x100001cc
>   Loading section .rela.dyn, size 0x24 vma 0x100001ec
>   Loading section .rela.plt, size 0x24 vma 0x10000210
>   Loading section .init, size 0x58 vma 0x10000234
>   Loading section .plt, size 0x44 vma 0x1000028c
>   Loading section .text, size 0x3d0 vma 0x100002d0
>   Loading section .fini, size 0x34 vma 0x100006a0
>   Loading section .rodata, size 0x12 vma 0x100006d4
>   Loading section .eh_frame, size 0x4 vma 0x100006e8
>   Loading section .ctors, size 0x8 vma 0x100016ec
>   Loading section .dtors, size 0x8 vma 0x100016f4
>   Loading section .jcr, size 0x4 vma 0x100016fc
>   Loading section .dynamic, size 0xd0 vma 0x10001700
>   Loading section .got, size 0xc vma 0x100017d0
>   Loading section .got.plt, size 0x18 vma 0x100017dc
>   Loading section .data, size 0x10 vma 0x100017f4
>   Start address 0x100002d0
>   Transfer rate: 14424 bits in <1 sec.
>   ERROR: Unknown opcode
>   program stopped with signal 4.
> 
> For me, I guess it is sim's issue, and I shall try to fix it in the next
> month, so sorry, I can not finish emulator for microblaze within this
> month. :-(
> 
> 
> Welcome any ideas, suggestions or completions.
> 
> Thanks.
> 

-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 09/25/2014 08:12 AM, Chen Gang wrote:
> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on Qemu, and try to make patches for it).
> 

Excuse me, after tried upstream qemu, it cann't run microblaze correctly,
even for Xilinx qemu branch, I cann't run correctly either. I tried to
consult related members in qemu mailing list, but got no result.

After compared upstream branch and Xilinx branch, I am sure upstream
microblaze qemu is lack of several related main features about
microblaze.

For qemu, I have to only focus on upstream, and try bug fix patches, new
features and version merging are out of my current border, so sorry, I
have to stop trying qemu for microblaze gcc test, at present.

>> So I guess the root cause is: I only use cross-compiling environments
>> under fedora x86_64, no any real or virtual target for test.
> 
> Yes, if you want to test on a target, you will need a target.  You can either have a simulator (see binutils and sim/* for an example of how to write one) or target hardware in some form.
> 

After trying sim, for me, it is really useful way for test, although I
also met issues:

For a hello world C program, microblaze gcc succeeded building, gdb can
load and display the source code, and disassembe code successfully, but
sim reported failure, the related issue is below:

  [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-run ./test
  Loading section .interp, size 0xd vma 0x100000f4
  Loading section .note.ABI-tag, size 0x20 vma 0x10000104
  Loading section .hash, size 0x24 vma 0x10000124
  Loading section .dynsym, size 0x40 vma 0x10000148
  Loading section .dynstr, size 0x3c vma 0x10000188
  Loading section .gnu.version, size 0x8 vma 0x100001c4
  Loading section .gnu.version_r, size 0x20 vma 0x100001cc
  Loading section .rela.dyn, size 0x24 vma 0x100001ec
  Loading section .rela.plt, size 0x24 vma 0x10000210
  Loading section .init, size 0x58 vma 0x10000234
  Loading section .plt, size 0x44 vma 0x1000028c
  Loading section .text, size 0x3d0 vma 0x100002d0
  Loading section .fini, size 0x34 vma 0x100006a0
  Loading section .rodata, size 0x12 vma 0x100006d4
  Loading section .eh_frame, size 0x4 vma 0x100006e8
  Loading section .ctors, size 0x8 vma 0x100016ec
  Loading section .dtors, size 0x8 vma 0x100016f4
  Loading section .jcr, size 0x4 vma 0x100016fc
  Loading section .dynamic, size 0xd0 vma 0x10001700
  Loading section .got, size 0xc vma 0x100017d0
  Loading section .got.plt, size 0x18 vma 0x100017dc
  Loading section .data, size 0x10 vma 0x100017f4
  Start address 0x100002d0
  Transfer rate: 14424 bits in <1 sec.
  ERROR: Unknown opcode
  program stopped with signal 4.

For me, I guess it is sim's issue, and I shall try to fix it in the next
month, so sorry, I can not finish emulator for microblaze within this
month. :-(


Welcome any ideas, suggestions or completions.

Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/5/14 11:32, Chen Gang wrote:
> On 10/5/14 11:15, Chen Gang wrote:
>> On 9/25/14 8:12, Chen Gang wrote:
>>> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on Qemu, and try to make patches for it).
>>>
>>> And, I also need finish the testsuite under Darwin x86_64, next month for gcc.
>>
>> I finish tried testsuit under Darwin x86_64, originally, I incorrectly
>> installed mpc: need "brew install libmpc", not "brew install mpc", and
>> also need "brew link libmpc" which I missed.
>>
>> At present, except for libjave Throw_2.exe test, I guess all others are
>> OK, please help check the result below, thanks. 
>>
> 
> Oh, sorry, I forgot to mention 2 things:
> 
>  - config with "--disable-multilibs", and I shall try normal configiure
>    again (although I guess, it will also be OK), hope I can finish
>    within 2 days.
> 
>  - And during test libjava, it will quit with error because of Throw_2,
>    so I modified the related Makefile to skip it.
>

After try normal configure, get almost the same result, I guess, our
testsuite under Darwin x86_64 is OK.

If no any additional reply within a week, I shall continue to try to
analyze the libjava Throw_2 issue.


Thanks.
 
> 
>> If it passes checking, next, I shall try to fix libjava Throw_2 issue
>> within this month (others, include Throw_1 and Throw_3 are all OK).
>>
>> 		=== g++ Summary ===
>>
>> # of expected passes		82961
>> # of unexpected failures	891
>> # of expected failures		255
>> # of unresolved testcases	272
>> # of unsupported tests		3421
>>
>> 		=== gcc Summary ===
>>
>> # of expected passes		85011
>> # of unexpected failures	30
>> # of expected failures		182
>> # of unresolved testcases	10
>> # of unsupported tests		2796
>>
>> 		=== gfortran Summary ===
>>
>> # of expected passes		46354
>> # of unexpected failures	1
>> # of expected failures		38
>> # of unsupported tests		74
>>
>> 		=== gnat Summary ===
>>
>> # of expected passes		799
>> # of unexpected failures	67
>> # of unexpected successes	18
>> # of unresolved testcases	382
>> # of unsupported tests		8
>>
>> 		=== objc Summary ===
>>
>> # of expected passes		5828
>> # of unexpected failures	4
>> # of expected failures		6
>> # of unsupported tests		77
>>
>> 		=== boehm-gc Summary ===
>>
>> # of expected passes		12
>> # of unsupported tests		1
>>
>> 		=== libatomic Summary ===
>>
>> # of expected passes		54
>>
>> 		=== libffi Summary ===
>>
>> # of expected passes		1819
>> # of unsupported tests		55
>>
>> 		=== libgomp Summary ===
>>
>> # of expected passes		3194
>> # of unsupported tests		38
>>
>> 		=== libitm Summary ===
>>
>> # of expected passes		26
>> # of expected failures		3
>> # of unsupported tests		1
>>
>> 		=== libjava Summary ===
>>
>> # of expected passes		2574
>> # of unexpected failures	4	/* The 4 issues are all related with Throw_2.exe */
>> # of expected failures		4
>> # of untested testcases		4
>>
>> 		=== libstdc++ Summary ===
>>
>> # of expected passes		8956
>> # of unexpected failures	159
>> # of expected failures		69
>> # of unresolved testcases	38
>> # of unsupported tests		670
>>
>>
>> Thanks.
>>
> 

-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 10/5/14 11:15, Chen Gang wrote:
> On 9/25/14 8:12, Chen Gang wrote:
>> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on Qemu, and try to make patches for it).
>>
>> And, I also need finish the testsuite under Darwin x86_64, next month for gcc.
> 
> I finish tried testsuit under Darwin x86_64, originally, I incorrectly
> installed mpc: need "brew install libmpc", not "brew install mpc", and
> also need "brew link libmpc" which I missed.
> 
> At present, except for libjave Throw_2.exe test, I guess all others are
> OK, please help check the result below, thanks. 
> 

Oh, sorry, I forgot to mention 2 things:

 - config with "--disable-multilibs", and I shall try normal configiure
   again (although I guess, it will also be OK), hope I can finish
   within 2 days.

 - And during test libjava, it will quit with error because of Throw_2,
   so I modified the related Makefile to skip it.


> If it passes checking, next, I shall try to fix libjava Throw_2 issue
> within this month (others, include Throw_1 and Throw_3 are all OK).
> 
> 		=== g++ Summary ===
> 
> # of expected passes		82961
> # of unexpected failures	891
> # of expected failures		255
> # of unresolved testcases	272
> # of unsupported tests		3421
> 
> 		=== gcc Summary ===
> 
> # of expected passes		85011
> # of unexpected failures	30
> # of expected failures		182
> # of unresolved testcases	10
> # of unsupported tests		2796
> 
> 		=== gfortran Summary ===
> 
> # of expected passes		46354
> # of unexpected failures	1
> # of expected failures		38
> # of unsupported tests		74
> 
> 		=== gnat Summary ===
> 
> # of expected passes		799
> # of unexpected failures	67
> # of unexpected successes	18
> # of unresolved testcases	382
> # of unsupported tests		8
> 
> 		=== objc Summary ===
> 
> # of expected passes		5828
> # of unexpected failures	4
> # of expected failures		6
> # of unsupported tests		77
> 
> 		=== boehm-gc Summary ===
> 
> # of expected passes		12
> # of unsupported tests		1
> 
> 		=== libatomic Summary ===
> 
> # of expected passes		54
> 
> 		=== libffi Summary ===
> 
> # of expected passes		1819
> # of unsupported tests		55
> 
> 		=== libgomp Summary ===
> 
> # of expected passes		3194
> # of unsupported tests		38
> 
> 		=== libitm Summary ===
> 
> # of expected passes		26
> # of expected failures		3
> # of unsupported tests		1
> 
> 		=== libjava Summary ===
> 
> # of expected passes		2574
> # of unexpected failures	4	/* The 4 issues are all related with Throw_2.exe */
> # of expected failures		4
> # of untested testcases		4
> 
> 		=== libstdc++ Summary ===
> 
> # of expected passes		8956
> # of unexpected failures	159
> # of expected failures		69
> # of unresolved testcases	38
> # of unsupported tests		670
> 
> 
> Thanks.
> 

-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

On 9/25/14 8:12, Chen Gang wrote:
> OK, thanks, next month, I shall try Qemu for microblaze (I also focus on Qemu, and try to make patches for it).
> 
> And, I also need finish the testsuite under Darwin x86_64, next month for gcc.

I finish tried testsuit under Darwin x86_64, originally, I incorrectly
installed mpc: need "brew install libmpc", not "brew install mpc", and
also need "brew link libmpc" which I missed.

At present, except for libjave Throw_2.exe test, I guess all others are
OK, please help check the result below, thanks. 

If it passes checking, next, I shall try to fix libjava Throw_2 issue
within this month (others, include Throw_1 and Throw_3 are all OK).

		=== g++ Summary ===

# of expected passes		82961
# of unexpected failures	891
# of expected failures		255
# of unresolved testcases	272
# of unsupported tests		3421

		=== gcc Summary ===

# of expected passes		85011
# of unexpected failures	30
# of expected failures		182
# of unresolved testcases	10
# of unsupported tests		2796

		=== gfortran Summary ===

# of expected passes		46354
# of unexpected failures	1
# of expected failures		38
# of unsupported tests		74

		=== gnat Summary ===

# of expected passes		799
# of unexpected failures	67
# of unexpected successes	18
# of unresolved testcases	382
# of unsupported tests		8

		=== objc Summary ===

# of expected passes		5828
# of unexpected failures	4
# of expected failures		6
# of unsupported tests		77

		=== boehm-gc Summary ===

# of expected passes		12
# of unsupported tests		1

		=== libatomic Summary ===

# of expected passes		54

		=== libffi Summary ===

# of expected passes		1819
# of unsupported tests		55

		=== libgomp Summary ===

# of expected passes		3194
# of unsupported tests		38

		=== libitm Summary ===

# of expected passes		26
# of expected failures		3
# of unsupported tests		1

		=== libjava Summary ===

# of expected passes		2574
# of unexpected failures	4	/* The 4 issues are all related with Throw_2.exe */
# of expected failures		4
# of untested testcases		4

		=== libstdc++ Summary ===

# of expected passes		8956
# of unexpected failures	159
# of expected failures		69
# of unresolved testcases	38
# of unsupported tests		670


Thanks.
-- 
Chen Gang

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

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

Thank you for your information, I shall notice about it when trying Qemu microblaze.

Thanks

Send from Lenovo A788t.

Michael Eager <eager@eagerm.com> wrote:

>On 09/24/14 09:23, Chen Gang wrote:
>> On 09/24/2014 11:37 PM, Mike Stump wrote:
>>> On Sep 24, 2014, at 8:28 AM, Michael Eager <eager@eagerm.com> wrote:
>>>>> After check the current result log, I find many remote target test
>>>>> related sentences, do we have to process it?
>>>>>
>>>>>    e.g. "Download to microblaze-xilinx-gdb failed, couldn't execute "rcp": no such file or directory."
>>>>
>>>> The test suite uses rcp to transfer files to or from the target,
>>>> either to provide input to a test case or to check the output.
>>>> Most Linux systems do not install rcp, since it is a security risk.
>>>
>>> To clarify:
>>>
>>>      if {[board_info $desthost exists rcp_prog]} {
>>>          set RCP [board_info $desthost rcp_prog]
>>>      } else {
>>>          set RCP rcp
>>>      }
>>>
>>> So, if you set rcp_prog to something else, you should be able to avoid rsh if you want.  Most people use ssh now-a-days.  You will want it set up to not require a password for testing.
>>>
>>
>> OK, thank you for your information.
>>
>> For one simple solving way under fedora: "yum install rsh", and I will
>> get another issue:
>>
>>    "Download to microblaze-xilinx-gdb failed, microblaze-xilinx-gdb: Unknown host"
>>
>> So I guess the root cause is: I only use cross-compiling environments
>> under fedora x86_64, no any real or virtual target for test.
>
>You can see the command which is getting the error by looking at gcc.log.
>If the command is not displayed, add another "-v" (or two) to RUNTESTFLAGS.
>
>If I recall correctly, DejaGNU is executing a command like "rcp file microblaze-xilinx-gdb".
>This means that you need to have the name microblaze-xilinx-gdb resolved into an IP address.
>This can be done by adding it to /etc/hosts.  Or you can specify the target IP address
>in the DejaGNU options.  I don't recall which one off the top of my head.
>
>-- 
>Michael Eager	 eager@eagercon.com
>1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Chen Gang]

OK, thanks, next month, I shall try Qemu for microblaze (I also focus on Qemu, and try to make patches for it).

And, I also need finish the testsuite under Darwin x86_64, next month for gcc.

Hope I can succeed.

Thanks

Send from Lenovo A788t.

Mike Stump <mikestump@comcast.net> wrote:

>On Sep 24, 2014, at 9:23 AM, Chen Gang <gang.chen.5i5j@gmail.com> wrote:
>> For one simple solving way under fedora: "yum install rsh", and I will
>> get another issue:
>> 
>>  "Download to microblaze-xilinx-gdb failed, microblaze-xilinx-gdb: Unknown host"
>> 
>> So I guess the root cause is: I only use cross-compiling environments
>> under fedora x86_64, no any real or virtual target for test.
>
>Yes, if you want to test on a target, you will need a target.  You can either have a simulator (see binutils and sim/* for an example of how to write one) or target hardware in some form.