| Message ID | 540DCB1B.40901@gmail.com |
|---|---|
| State | New |
| Headers | show |
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. >
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.
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.
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. >
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.
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.
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.
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.
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. >
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. >> > >
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. >>> >> >> > >
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.
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.
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
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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))] ""