subject:"\[PATCH\] microblaze\: microblaze.md\: Use 'SI' instead of 'VOID' for operand 1 of 'call_value

On 06/10/14 05:08, Chen Gang wrote:
 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.

Throw_2 is a test specially contrived to detect segfaults that are
not being correctly detected and turned into NullPointerException()s.
A failure indicates that the segfault signal handler is broken.

Andrew.

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

On 10/6/14 16:37, Andrew Haley wrote:
 On 06/10/14 05:08, Chen Gang wrote:
 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.
 
 Throw_2 is a test specially contrived to detect segfaults that are
 not being correctly detected and turned into NullPointerException()s.
 A failure indicates that the segfault signal handler is broken.
 

OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
and after run it without any parameters, 1 is printed, but 2 is not
printed.

Under Fedora 20 x86_64, the same gcc code, it is OK (2 can be printed),
but under Darwin x86_64, it is Abort trap: 6 instead of. The related
code: try{Double.parseDouble(str());}catch, and str(){return null;}.

And I shall continue to try to analyze it (within this month), and 
welcome any additional ideas, suggestions, and completion for it, 


Thanks
-- 
Chen Gang

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

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

On 10/06/2014 02:53 PM, Chen Gang wrote:
 On 10/6/14 16:37, Andrew Haley wrote:
 On 06/10/14 05:08, Chen Gang wrote:
 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.

 Throw_2 is a test specially contrived to detect segfaults that are
 not being correctly detected and turned into NullPointerException()s.
 A failure indicates that the segfault signal handler is broken.
 
 OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
 and after run it without any parameters, 1 is printed, but 2 is not
 printed.
 
 Under Fedora 20 x86_64, the same gcc code, it is OK (2 can be printed),
 but under Darwin x86_64, it is Abort trap: 6 instead of. The related
 code: try{Double.parseDouble(str());}catch, and str(){return null;}.
 
 And I shall continue to try to analyze it (within this month), and 
 welcome any additional ideas, suggestions, and completion for it, 

Not every platform supports unwinding through signal handlers.  In x86
Linux there is some very clever code which interacts with the kernel to
allow this.

Andrew.

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

On 10/6/14 21:54, Andrew Haley wrote:
 On 10/06/2014 02:53 PM, Chen Gang wrote:
 On 10/6/14 16:37, Andrew Haley wrote:
 On 06/10/14 05:08, Chen Gang wrote:
 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.

 Throw_2 is a test specially contrived to detect segfaults that are
 not being correctly detected and turned into NullPointerException()s.
 A failure indicates that the segfault signal handler is broken.

 OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
 and after run it without any parameters, 1 is printed, but 2 is not
 printed.

 Under Fedora 20 x86_64, the same gcc code, it is OK (2 can be printed),
 but under Darwin x86_64, it is Abort trap: 6 instead of. The related
 code: try{Double.parseDouble(str());}catch, and str(){return null;}.

 And I shall continue to try to analyze it (within this month), and 
 welcome any additional ideas, suggestions, and completion for it, 
 
 Not every platform supports unwinding through signal handlers.  In x86
 Linux there is some very clever code which interacts with the kernel to
 allow this.
 

Excuse me, I am not quite familiar with Java, I guess what you said is:

 - The related feature need OS kernel support, if OS kernel does not
   support, it may report Abort trap: 6 or others.

 - And OS kernel has feature to support 1 printed does not mean it
   also has feature to support 2 printed.

 - And I need try to make sure that my current Darwin kernel whether
   supports it or not.

If what I guess is incorrect, please let me know, thanks.

For me, whether Darwin kernel supports or not, we have to improve
current implementation (may be testsuite configure or Makefile) to
avoid testsuite breaking.


Thanks.
-- 
Chen Gang

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

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

On 10/06/2014 03:27 PM, Chen Gang wrote:
 On 10/6/14 21:54, Andrew Haley wrote:
 On 10/06/2014 02:53 PM, Chen Gang wrote:
 On 10/6/14 16:37, Andrew Haley wrote:
 On 06/10/14 05:08, Chen Gang wrote:
 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.

 Throw_2 is a test specially contrived to detect segfaults that are
 not being correctly detected and turned into NullPointerException()s.
 A failure indicates that the segfault signal handler is broken.

 OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
 and after run it without any parameters, 1 is printed, but 2 is not
 printed.

 Under Fedora 20 x86_64, the same gcc code, it is OK (2 can be printed),
 but under Darwin x86_64, it is Abort trap: 6 instead of. The related
 code: try{Double.parseDouble(str());}catch, and str(){return null;}.

 And I shall continue to try to analyze it (within this month), and 
 welcome any additional ideas, suggestions, and completion for it, 

 Not every platform supports unwinding through signal handlers.  In x86
 Linux there is some very clever code which interacts with the kernel to
 allow this.
 
 Excuse me, I am not quite familiar with Java, I guess what you said is:
 
  - The related feature need OS kernel support, if OS kernel does not
support, it may report Abort trap: 6 or others.
 
  - And OS kernel has feature to support 1 printed does not mean it
also has feature to support 2 printed.
 
  - And I need try to make sure that my current Darwin kernel whether
supports it or not.
 
 If what I guess is incorrect, please let me know, thanks.

That sounds approximately right, but it's changed a lot since I last
looked.  It may be that the magic is in glibc rather than the kernel.

 For me, whether Darwin kernel supports or not, we have to improve
 current implementation (may be testsuite configure or Makefile) to
 avoid testsuite breaking.

The testsuite isn't breaking: it's telling you something useful.

Andrew.

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

On 10/6/14 22:28, Andrew Haley wrote:
 On 10/06/2014 03:27 PM, Chen Gang wrote:
 On 10/6/14 21:54, Andrew Haley wrote:
 On 10/06/2014 02:53 PM, Chen Gang wrote:
 On 10/6/14 16:37, Andrew Haley wrote:
 On 06/10/14 05:08, Chen Gang wrote:
 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.

 Throw_2 is a test specially contrived to detect segfaults that are
 not being correctly detected and turned into NullPointerException()s.
 A failure indicates that the segfault signal handler is broken.

 OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
 and after run it without any parameters, 1 is printed, but 2 is not
 printed.

 Under Fedora 20 x86_64, the same gcc code, it is OK (2 can be printed),
 but under Darwin x86_64, it is Abort trap: 6 instead of. The related
 code: try{Double.parseDouble(str());}catch, and str(){return null;}.

 And I shall continue to try to analyze it (within this month), and 
 welcome any additional ideas, suggestions, and completion for it, 

 Not every platform supports unwinding through signal handlers.  In x86
 Linux there is some very clever code which interacts with the kernel to
 allow this.

 Excuse me, I am not quite familiar with Java, I guess what you said is:

  - The related feature need OS kernel support, if OS kernel does not
support, it may report Abort trap: 6 or others.

  - And OS kernel has feature to support 1 printed does not mean it
also has feature to support 2 printed.

  - And I need try to make sure that my current Darwin kernel whether
supports it or not.

 If what I guess is incorrect, please let me know, thanks.
 
 That sounds approximately right, but it's changed a lot since I last
 looked.  It may be that the magic is in glibc rather than the kernel.


OK, thanks, I shall also notice about glibc when I try to analyze it,
e.g. need try to build and install upstream glibc instead of the Darwin
glibc (I am not quite sure whether I can do that, I guess I can).

 
 For me, whether Darwin kernel supports or not, we have to improve
 current implementation (may be testsuite configure or Makefile) to
 avoid testsuite breaking.
 
 The testsuite isn't breaking: it's telling you something useful.
 

Sorry it is breaked, at present, I temporarily skipped it and then can
let make check finish, the related temporarily skip diff may like
below (in real action, I modify the related Makefile, directly):

diff --git a/libjava/testsuite/Makefile.in b/libjava/testsuite/Makefile.in
index 28fc102..d1e77de 100644
--- a/libjava/testsuite/Makefile.in
+++ b/libjava/testsuite/Makefile.in
@@ -390,7 +390,7 @@ check-DEJAGNU: site.exp
if $(SHELL) -c $$runtest --version  /dev/null 21; then \
  exit_status=0; l='$(DEJATOOL)'; for tool in $$l; do \
if $$runtest $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS) 
$(RUNTESTFLAGS); \
-   then :; else exit_status=1; fi; \
+   then :; else exit_status=0; fi; \
  done; \
else echo WARNING: could not find \`runtest' 12; :;\
fi; \
ba

Thanks.
-- 
Chen Gang

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

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

On 10/06/2014 04:00 PM, Chen Gang wrote:
 On 10/6/14 22:28, Andrew Haley wrote:
 On 10/06/2014 03:27 PM, Chen Gang wrote:
 On 10/6/14 21:54, Andrew Haley wrote:
 On 10/06/2014 02:53 PM, Chen Gang wrote:
 On 10/6/14 16:37, Andrew Haley wrote:
 On 06/10/14 05:08, Chen Gang wrote:
 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.

 Throw_2 is a test specially contrived to detect segfaults that are
 not being correctly detected and turned into NullPointerException()s.
 A failure indicates that the segfault signal handler is broken.

 OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
 and after run it without any parameters, 1 is printed, but 2 is not
 printed.

 Under Fedora 20 x86_64, the same gcc code, it is OK (2 can be printed),
 but under Darwin x86_64, it is Abort trap: 6 instead of. The related
 code: try{Double.parseDouble(str());}catch, and str(){return null;}.

 And I shall continue to try to analyze it (within this month), and 
 welcome any additional ideas, suggestions, and completion for it, 

 Not every platform supports unwinding through signal handlers.  In x86
 Linux there is some very clever code which interacts with the kernel to
 allow this.

 Excuse me, I am not quite familiar with Java, I guess what you said is:

  - The related feature need OS kernel support, if OS kernel does not
support, it may report Abort trap: 6 or others.

  - And OS kernel has feature to support 1 printed does not mean it
also has feature to support 2 printed.

  - And I need try to make sure that my current Darwin kernel whether
supports it or not.

 If what I guess is incorrect, please let me know, thanks.

 That sounds approximately right, but it's changed a lot since I last
 looked.  It may be that the magic is in glibc rather than the kernel.

 
 OK, thanks, I shall also notice about glibc when I try to analyze it,
 e.g. need try to build and install upstream glibc instead of the Darwin
 glibc (I am not quite sure whether I can do that, I guess I can).
 
  
 For me, whether Darwin kernel supports or not, we have to improve
 current implementation (may be testsuite configure or Makefile) to
 avoid testsuite breaking.

 The testsuite isn't breaking: it's telling you something useful.

 
 Sorry it is breaked, at present, I temporarily skipped it and then can
 let make check finish, the related temporarily skip diff may like
 below (in real action, I modify the related Makefile, directly):

You're missing what I'm saying.  The testuite is not broken.

You should be running make -k check.

Andrew.

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

On 10/6/14 22:59, Andrew Haley wrote:
 On 10/06/2014 04:00 PM, Chen Gang wrote:
 On 10/6/14 22:28, Andrew Haley wrote:
[...]
 The testsuite isn't breaking: it's telling you something useful.


 Sorry it is breaked, at present, I temporarily skipped it and then can
 let make check finish, the related temporarily skip diff may like
 below (in real action, I modify the related Makefile, directly):
 
 You're missing what I'm saying.  The testuite is not broken.
 
 You should be running make -k check.
 

For me, make -k check is suitable for one sub-system (e.g. for cross
building, and mainly focus on gcc), but not for global check (full
non-cross building check):

 - make check is the standard check for global, so when find new
   issues (include environment construction), need stop in time.

 - If one sub-system wants to skip the known issue, it can mark it as
   'unexpected', or just simply return 0 to Makefile to let checking
   continue (I guess, most of other sub-system do in this way).

 - Or for other members (especially for newbies, e.g. me), he/she can
   not sure whether the environment construction for testsuite is OK or
   not:

 e.g. For our case, after build upstream glibc and let testsuite use
 it instead of Darwin glibc, all things may go OK. If really it is,
 it is environments construction (not testsuite or code) issue.


Thanks.
-- 
Chen Gang

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

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

2014-10-06 Thread Mike Stump

On Oct 6, 2014, at 8:36 AM, Chen Gang gang.chen.5...@gmail.com wrote:
 For me, make -k check is suitable for one sub-system (e.g. for cross
 building, and mainly focus on gcc), but not for global check (full
 non-cross building check):

In our world, there is no sub-system, so, talk of such is outside the scope of 
gcc.

Let me repeat what he said differently.

You have two choices, fixing the port so that there are no unexpected failures 
or running check with -k.

I’d like to get to the point where all primary/secondary platforms can use make 
check directly, we’re not there yet.

The idea is that the single return value tells if if the suite passed or not.  
This is an absolute measure, that, when achieved means one never has to compare 
previous/present results, just know that the suite passed.  Sometimes simple is 
better.

 - make check is the standard check for global,

No sub-system, no global.

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

On 10/7/14 1:29, Mike Stump wrote:
 On Oct 6, 2014, at 8:36 AM, Chen Gang gang.chen.5...@gmail.com wrote:
 For me, make -k check is suitable for one sub-system (e.g. for cross
 building, and mainly focus on gcc), but not for global check (full
 non-cross building check):
 
 In our world, there is no sub-system, so, talk of such is outside the scope 
 of gcc.
 
 Let me repeat what he said differently.
 
 You have two choices, fixing the port so that there are no unexpected 
 failures or running check with -k.
 
 I’d like to get to the point where all primary/secondary platforms can use 
 make check directly, we’re not there yet.
 
 The idea is that the single return value tells if if the suite passed or not. 
  This is an absolute measure, that, when achieved means one never has to 
 compare previous/present results, just know that the suite passed.  Sometimes 
 simple is better.
 
 - make check is the standard check for global,
 
 No sub-system, no global.
 

Theoretically, in each system (include gcc), always can be separated
into several 'sub-systems', and then 'global' means the system itself.

In our case, we say let 'global' pass checking means let gcc, gfortran,
g++, libjava ... all pass checking. But for mainly focus on constructing
environments, I will try to use upstream glibc instead of Darwin glibc:

 - If fix Throw_2, we know it is environments construction issue.

 - Else, I shall skip it (since make -k check should be OK).

And after finish testsuite under Darwin, within this month, I shall try
to find and send a patch for gcc, and pass testsuite under Darwin (it
seems it is not quite difficult to me).


Thanks
-- 
Chen Gang

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

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

On 10/7/14 7:18, Chen Gang wrote:
 On 10/7/14 1:29, Mike Stump wrote:
 On Oct 6, 2014, at 8:36 AM, Chen Gang gang.chen.5...@gmail.com wrote:
 For me, make -k check is suitable for one sub-system (e.g. for cross
 building, and mainly focus on gcc), but not for global check (full
 non-cross building check):

 In our world, there is no sub-system, so, talk of such is outside the scope 
 of gcc.

 Let me repeat what he said differently.

 You have two choices, fixing the port so that there are no unexpected 
 failures or running check with -k.

 I’d like to get to the point where all primary/secondary platforms can use 
 make check directly, we’re not there yet.

 The idea is that the single return value tells if if the suite passed or 
 not.  This is an absolute measure, that, when achieved means one never has 
 to compare previous/present results, just know that the suite passed.  
 Sometimes simple is better.

 - make check is the standard check for global,

 No sub-system, no global.

 
 Theoretically, in each system (include gcc), always can be separated
 into several 'sub-systems', and then 'global' means the system itself.
 
 In our case, we say let 'global' pass checking means let gcc, gfortran,
 g++, libjava ... all pass checking. But for mainly focus on constructing
 environments, I will try to use upstream glibc instead of Darwin glibc:
 
  - If fix Throw_2, we know it is environments construction issue.
 
  - Else, I shall skip it (since make -k check should be OK).
 
 And after finish testsuite under Darwin, within this month, I shall try
 to find and send a patch for gcc, and pass testsuite under Darwin (it
 seems it is not quite difficult to me).
 
 

It is really unlucky, The upstream glibc does not support Darwin! And
sorry, send patches to glibc is really out of my current border, so I
have to give up. :-(

  bash-3.2# ../glibc/configure --with-prefix=/release/Darwin/ 
--with-sysroot=/release/Darwin
  checking build system type... x86_64-apple-darwin13.4.0
  checking host system type... x86_64-apple-darwin13.4.0
  checking for gcc... gcc
  checking for suffix of object files... o
  checking whether we are using the GNU C compiler... yes
  checking whether gcc accepts -g... yes
  checking for g++... g++
  checking whether we are using the GNU C++ compiler... yes
  checking whether g++ accepts -g... yes
  checking for readelf... no
  checking for sysdeps preconfigure fragments... aarch64 alpha arm hppa i386 
m68k microblaze mips powerpc s390 sh sparc tile x86_64 checking whether gcc 
compiles in -mx32 mode by default... no
  
  configure: running configure fragment for add-on libidn
  *** The GNU C library is currently not available for this platform.
  *** So far nobody cared to port it and if there is no volunteer it
  *** might never happen.  So, if you have interest to see glibc on
  *** this platform visit
  ***   http://www.gnu.org/software/libc/porting.html
  *** and join the group of porters


And I guess, this thread can be ended, and next, I shall try to find a
patch for gcc, and let it pass testsuite under Darwin.


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'

2014-10-05 Thread 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 testcases272
 # of unsupported tests   3421

  === gcc Summary ===

 # of expected passes 85011
 # of unexpected failures 30
 # of expected failures   182
 # of unresolved testcases10
 # 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 successes18
 # of unresolved testcases382
 # 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 testcases38
 # 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'

2014-10-04 Thread 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 passes82961
# of unexpected failures891
# of expected failures  255
# of unresolved testcases   272
# of unsupported tests  3421

=== gcc Summary ===

# of expected passes85011
# of unexpected failures30
# of expected failures  182
# of unresolved testcases   10
# of unsupported tests  2796

=== gfortran Summary ===

# of expected passes46354
# of unexpected failures1
# of expected failures  38
# of unsupported tests  74

=== gnat Summary ===

# of expected passes799
# of unexpected failures67
# of unexpected successes   18
# of unresolved testcases   382
# of unsupported tests  8

=== objc Summary ===

# of expected passes5828
# of unexpected failures4
# of expected failures  6
# of unsupported tests  77

=== boehm-gc Summary ===

# of expected passes12
# of unsupported tests  1

=== libatomic Summary ===

# of expected passes54

=== libffi Summary ===

# of expected passes1819
# of unsupported tests  55

=== libgomp Summary ===

# of expected passes3194
# of unsupported tests  38

=== libitm Summary ===

# of expected passes26
# of expected failures  3
# of unsupported tests  1

=== libjava Summary ===

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

=== libstdc++ Summary ===

# of expected passes8956
# of unexpected failures159
# 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'

2014-10-04 Thread 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 failures255
 # of unresolved testcases 272
 # of unsupported tests3421
 
   === gcc Summary ===
 
 # of expected passes  85011
 # of unexpected failures  30
 # of expected failures182
 # of unresolved testcases 10
 # of unsupported tests2796
 
   === gfortran Summary ===
 
 # of expected passes  46354
 # of unexpected failures  1
 # of expected failures38
 # of unsupported tests74
 
   === gnat Summary ===
 
 # of expected passes  799
 # of unexpected failures  67
 # of unexpected successes 18
 # of unresolved testcases 382
 # of unsupported tests8
 
   === objc Summary ===
 
 # of expected passes  5828
 # of unexpected failures  4
 # of expected failures6
 # of unsupported tests77
 
   === boehm-gc Summary ===
 
 # of expected passes  12
 # of unsupported tests1
 
   === libatomic Summary ===
 
 # of expected passes  54
 
   === libffi Summary ===
 
 # of expected passes  1819
 # of unsupported tests55
 
   === libgomp Summary ===
 
 # of expected passes  3194
 # of unsupported tests38
 
   === libitm Summary ===
 
 # of expected passes  26
 # of expected failures3
 # of unsupported tests1
 
   === libjava Summary ===
 
 # of expected passes  2574
 # of unexpected failures  4   /* The 4 issues are all related with 
 Throw_2.exe */
 # of expected failures4
 # of untested testcases   4
 
   === libstdc++ Summary ===
 
 # of expected passes  8956
 # of unexpected failures  159
 # of expected failures69
 # of unresolved testcases 38
 # of unsupported tests670
 
 
 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'

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 passes65987
# of unexpected failures82
# 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 failures97
# of unresolved testcases 16570
# of unsupported tests1854

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'

2014-09-24 Thread 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 passes65987
 # of unexpected failures82
 # 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 failures97
 # of unresolved testcases 16570
 # of unsupported tests1854

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 Eagerea...@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'

2014-09-24 Thread Mike Stump

On Sep 24, 2014, at 8:28 AM, Michael Eager ea...@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'

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 passes65987
  # of unexpected failures82
  # 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'

On 09/24/2014 11:37 PM, Mike Stump wrote:
 On Sep 24, 2014, at 8:28 AM, Michael Eager ea...@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'

2014-09-24 Thread Mike Stump

On Sep 24, 2014, at 9:23 AM, Chen Gang gang.chen.5...@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'

2014-09-24 Thread 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 ea...@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 Eagerea...@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'

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 mikest...@comcast.net wrote:

On Sep 24, 2014, at 9:23 AM, Chen Gang gang.chen.5...@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'

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

Thanks

Send from Lenovo A788t.

Michael Eager ea...@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 ea...@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   ea...@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'

2014-09-22 Thread 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 Eagerea...@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'

2014-09-22 Thread 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 Eagerea...@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'

2014-09-22 Thread 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'

2014-09-22 Thread 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'

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 failures97
# of unresolved testcases 16570
# of unsupported tests1854
/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'

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!

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:

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.

gcc result:

=== gcc Summary ===

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'

2014-09-21 Thread 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 Eagerea...@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'

2014-09-21 Thread 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 1180


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 Eagerea...@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'



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'