This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
- From: Chen Gang <gang dot chen dot 5i5j at gmail dot com>
- To: Michael Eager <eager at eagerm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Jeff Law <law at redhat dot com>, davem at redhat dot com
- Date: Sun, 21 Sep 2014 14:24:47 +0800
- Subject: Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
- Authentication-results: sourceware.org; auth=none
- References: <53B9246A dot 5090408 at gmail dot com> <53EB7FE3 dot 40406 at eagerm dot com> <53EC1264 dot 2080205 at gmail dot com> <540C7703 dot 7090303 at gmail dot com> <540D1363 dot 10909 at gmail dot com> <540DCB1B dot 40901 at gmail dot com> <54154907 dot 2000007 at gmail dot com> <541656FE dot 8020008 at eagerm dot com> <541668CF dot 5080206 at gmail dot com> <54170603 dot 8090607 at eagerm dot com> <54176DCF dot 403 at gmail dot com> <54182E13 dot 1090006 at eagerm dot com> <541DA2A0 dot 5040200 at gmail dot com> <541DABEC dot 7090705 at eagerm dot com> <541DAE2B dot 8050104 at gmail dot com>
After check the details, I guess, we need:
- Cross compile and install glibc with raw microblaze cross-compiler,
- Then compile new microblaze cross compiler with glibc.
- Then make check the new microblaze cross compiler with glibc.
And it seems, we also need 'LinkScr.ld' for ldscript, could you share it
to me, thanks.
set_board_info ldscript "-T/home/eager/Xilinx/dg/microblaze_0/LinkScr.ld"
At present, I am just analyzing how to cross compile microblaze glibc,
welcome any ideas, suggestions or completions.
Thanks.
On 09/21/2014 12:41 AM, Chen Gang wrote:
>
> Thank you very much for your quickly response, I shall continue try.
>
> Thanks.
>
> On 09/21/2014 12:31 AM, Michael Eager wrote:
>> On 09/20/14 08:52, Chen Gang wrote:
>>
>>> Thank you very much for your attachments, it is very useful to me!
>>>
>>> I tried testsuite for microblaze cross target on x86_64 host, it says
>>> OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
>>> that my configuration is incorrect), please help check, thanks.
>>
>> Welcome to the joys of DejaGNU. Configuration can be confusing.
>> As you can see, the return code is not useful.
>>
>>> dejagnu configuration:
>>>
>>> cp xmd.exp /usr/local/share/dejagnu/config/
>>> cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
>>> vi microblaze-xilinx-gdb.exp
>>> "s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
>>>
>>> gcc operation:
>>>
>>> ../gcc/configure --target=microblaze-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared \
>>> --without-headers --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
>>> make
>>> make -k check-gcc RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"
>>
>> Check whether these compiler options are being passed to mb-gcc. There is a
>> line in my microblaze-xilinx-gdb.exp which sets CFLAGS:
>> set_board_info cflags "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
>> This is likely overriding any options passed to runtest.
>>
>> Make sure that the options match the features of your target board. You might
>> not need any options for your initial tests.
>>
>> Make sure that the correct flags are being passed to the linker.
>>
>> Add "-v" or "-v -v" to RUNTESTFLAGS so that the gcc.log file gives useful info.
>>
>> You might want to limit the number of tests run until you get problems worked out:
>> make check-gcc RUNTESTFLAGS="execute.exp -v -v --target_board=microblaze-xilinx-gdb"
>> This will run only the gcc.c-torture/execute/execute.exp tests.
>>
>>> gcc result:
>>>
>>> === gcc Summary ===
>>>
>>> # of expected passes 48408
>>> # of unexpected failures 17253
>>> # of unexpected successes 1
>>> # of expected failures 97
>>> # of unresolved testcases 16570
>>> # of unsupported tests 1854
>>> /upstream/build-gcc/gcc/xgcc version 5.0.0 20140920 (experimental) (GCC)
>>
>> Look at gcc.sum and gcc.log to find out what is causing the large number of
>> unexpected failures. A large number of unresolved test cases often means that
>> the compiler returned an error.
>>
>
>
--
Chen Gang
Open share and attitude like air water and life which God blessed