[PATCH] [Microblaze]: PIC Data Text Relative
Andrew Sadek
andrew.sadek.se@gmail.com
Tue Mar 13 07:56:00 GMT 2018
Ok, so you mean with '-fPIC -mpic-data-text-relative' as I do in my test
case ?
If all is Ok, execution and compilation shall ideally pass for the test
cases.
But I have noticed that there are some output pattern checks done in some
test cases and this may fail since the output assembly is different,
anyway I shall give it a try and send you the results with the new options.
On Tue, Mar 13, 2018 at 8:42 AM, Michael Eager <eager@eagerm.com> wrote:
> On 03/12/18 23:10, Andrew Sadek wrote:
>
>> _Command for running testsuite:_
>>
>> /make -k check-gcc RUNTESTFLAGS="-v --target_board=microblaze-qemu
>> CFLAGS_FOR_TARGET='-include /home/andrew/qemu/common.h
>> -L/home/andrew/qemu/lib -Wl,--start-group,-lxil,-lgcc,-lc,--end-group
>> -mlittle-endian' "/
>>
>> _Quick Details:_
>> 1) common.h: Here I define 'STACK_SIZE' with (0x4000) as it's used in
>> some test cases.
>> 2) -L ..... /lib: it contains libm, libc in little endian since we use
>> 'qemu-system-microblazeel', and libxil which is the libgloss + some
>> additional features (read, write, inbyte, outbyte) built with Xilinx SDK.
>>
>> _mb-gcc command example from gcc.log:_
>>
>> Testing execute/va-arg-15.c, -O1
>> doing compile
>> Executing on host://home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-
>> elf/build/build-cc-gcc-final/gcc/xgcc -B/home/andrew/gcc_workspace/g
>> cc_orig/microblaze-xilinx-elf/build/build-cc-gcc-final/gcc/
>> /home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/
>> src/gcc/gcc/testsuite/gcc.c-torture/execute/va-arg-15.c -include
>> /home/andrew/qemu/common.h -L/home/andrew/qemu/lib
>> -Wl,--start-group,-lxil,-lgcc,-lc,--end-group -mlittle-endian
>> -fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -w
>> -T/home/andrew/qemu/qemu/microblazeel-softmmu/xilinx.ld -lm -o
>> ./va-arg-15.exe (timeout = 300)/
>>
>
> OK. This shows that the patch does not cause regressions when the new
> options are not used. That is good.
>
> Please run the same regression test with the new PIC options. Ideally you
> should have the same results.
>
>
>
>>
>>
>> On Mon, Mar 12, 2018 at 4:30 PM, Michael Eager <eager@eagerm.com <mailto:
>> eager@eagerm.com>> wrote:
>>
>> On 03/12/18 06:19, Andrew Sadek wrote:
>>
>>
>>
>> On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager <eager@eagerm.com
>> <mailto:eager@eagerm.com> <mailto:eager@eagerm.com
>>
>> <mailto:eager@eagerm.com>>> wrote:
>>
>> On 03/02/2018 08:12 AM, Andrew Sadek wrote:
>>
>> Hello Michael,
>>
>> I tried running the whole GCC test suite on the current
>> head
>> (without my patch) along with 'microblaze-qemu' but I
>> have the
>> following problems:
>>
>> 1) The test is hanging at
>> 'gcc.c-torture/string-large-1.c' , the
>> gcc is making a 100% CPU usage and the machine stucks.
>> I tried compiling the file alone, it generated a couple
>> of
>> warnings than it hangs.
>> warning: '__builtin_memchr' specified size
>> 4294967295 exceeds
>> maximum object size 2147483647 [-Wstringop-overflow=]
>> vp1 = __builtin_memchr (a, b, SIZE1);
>>
>> Is it a bug? Is there something wrong with my
>> configuration ?
>> GCC configured with options : --with-newlib
>> --enable-threads=no
>> --disable-shared --with-pkgversion='crosstool-NG
>> crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit
>> --disable-libgomp --disable-libmudflap --disable-libmpx
>> --disable-libssp --disable-libquadmath
>> --disable-libquadmath-support --enable-lto
>> --with-host-libstdcxx='-static-libgcc
>> -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
>> --enable-target-optspace
>> --disable-nls --enable-multiarch --enable-languages=c,c++
>>
>>
>> Your configuration is more complex than my hard-metal
>> target version,
>> but it looks reasonable.
>>
>> The problem with string-large-1.c does appear to be a bug.
>> You can
>> add a line to the test case which will mark it as known
>> failure for MB:
>>
>> /* { dg-xfail-if "exceeds maximum" { microblaze-*-* } } */
>>
>> (I have not tested this, but it should work. Compare with
>> other
>> xfail's.)
>>
>>
>> Problem that the whole compile package is invoked with '-w'
>> which inhibits all warnings and overrides ' -Werror' as well as
>> ' -Wfatal-errors' .
>> As a result, the warning message does not appear when running
>> compile.exp. Any suggestions ? Do I remove the '-w' ?
>>
>>
>>
>> 2) For running QEMU, I have no problem with elf
>> execution. But I
>> do not know how to auto terminate the QEMU itself as
>> it remains
>> up even after program execution.
>> Is there some command to be passed to QEMU in order
>> make system
>> shut down after program termination with its exit code ?
>>
>>
>> Yes, this is a problem. For other targets using QEMU I
>> have added dummy
>> HLT instructions to terminate QEMU, or used a wrapper
>> around QEMU which
>> sets breakpoints at exit (or _exit) and stops the simulator
>> when hit.
>>
>> If you are running Linux on QEMU, instead of using QEMU's
>> built-in gdb
>> interface you might use the Linux system as the target for
>> the test
>> suite, running gdbserver on the target.
>>
>>
>> I have finally managed to fully run QEMU with test suite but had
>> to make a local modification in the QEMU code itself.
>> In the translate function, I make a check if "bri 0" is reached
>> which is the '_exit'. Then, abort the QE
>> <https://maps.google.com/?q=h+is+the+'_exit'.+Then,+abort+the+QE&entry=gmail&source=g>MU
>> app with the exit
>> code stored in 'r5'.
>>
>>
>> I've done essentially the same for
>> <https://maps.google.com/?q=I've+done+essentially+the+same+for+&entry=gmail&source=g>other
>> targets.
>>
>> Here are the results below:
>> _Without Patch:_
>> === gcc Summary ===
>>
>> # of expected passes90776
>> # of unexpected failures 1317
>> # of unexpected successes3
>> # of expected failures207
>> # of unresolved testcases115
>> # of unsupported tests2828
>>
>> _With Patch and after adding my test case:_
>> === gcc Summary ===
>>
>> # of expected passes90790
>> # of unexpected failures1317
>> # of unexpected successes3
>> # of expected failures207
>> # of unresolved testcases115
>> # of unsupported tests2828
>>
>>
>> This appears to be reasonable results. It appears that there are no
>> regressions.
>>
>> Please send me the mb-gcc command line options for both of these
>> test runs.
>>
>>
>>
>>
>> -- Michael Eager eager@eagerm.com <mailto:eager@eagerm.com>
>> 1960 Park Blvd., Palo Alto, CA 94306
>>
>>
>>
>>
>> --
>>
>> Andrew
>>
>
> --
> Michael Eager eager@eagerm.com
> 1960 Park Blvd., Palo Alto, CA 94306
>
--
Andrew
More information about the Gcc-patches
mailing list