From: Andrew Sadek <andrew.sadek.se@gmail.com>
To: Michael Eager <eager@eagerm.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] [Microblaze]: PIC Data Text Relative
Date: Tue, 13 Mar 2018 06:10:00 -0000 [thread overview]
Message-ID: <CAE=jbAOsht1g3EDCZeaqZ7A3JnVvziN-0AcZTOMTseq5sogW5Q@mail.gmail.com> (raw)
In-Reply-To: <71c573a2-af37-9dfb-bbd1-b69bd2b56cbf@eagerm.com>
*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/gcc_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)*
On Mon, Mar 12, 2018 at 4:30 PM, Michael Eager <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>> 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 QEMU app with the exit code stored in 'r5'.
>>
>
> I've done essentially the same for 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
> 1960 Park Blvd., Palo Alto, CA 94306
>
--
Andrew
next prev parent reply other threads:[~2018-03-13 6:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAE=jbAMyXXpWUPnC_dcmyWNeOXcJ-Wo4+KomQ9KwpX2KuLDqkg@mail.gmail.com>
2018-02-27 0:07 ` Michael Eager
2018-02-27 8:14 ` Andrew Sadek
2018-03-02 16:12 ` Andrew Sadek
2018-03-05 19:21 ` Michael Eager
2018-03-12 13:19 ` Andrew Sadek
2018-03-12 14:30 ` Michael Eager
2018-03-13 6:10 ` Andrew Sadek [this message]
2018-03-13 6:42 ` Michael Eager
2018-03-13 7:56 ` Andrew Sadek
2018-03-13 20:51 ` Michael Eager
[not found] ` <CAE=jbAMCJ_8HR=ztOrY_FLfhYEMAFivyMO=Tz8EBdagd9zgs5g@mail.gmail.com>
2018-03-18 14:56 ` Andrew Sadek
2018-03-19 20:09 ` Michael Eager
2018-03-20 1:30 ` Michael Eager
2018-03-20 2:06 ` Michael Eager
2018-03-20 14:18 ` Andrew Sadek
2018-03-20 15:49 ` Michael Eager
2018-03-22 18:45 ` Andrew Sadek
2018-04-18 12:44 ` Andrew Sadek
2018-04-18 16:57 ` Michael Eager
2018-04-19 10:43 ` Andrew Sadek
2018-04-27 1:41 ` Michael Eager
2018-04-27 10:41 ` Andrew Sadek
[not found] ` <1285bbac-fa9c-34f5-c43d-82c0c17d89c9@eagerm.com>
2018-05-03 17:13 ` Andrew Sadek
2018-05-05 11:17 ` Andrew Sadek
[not found] ` <CAE=jbAMZJTQsEygLtPpXaSi=YGkOFje92CpEc6KhuuZk5HWCLA@mail.gmail.com>
2018-05-06 11:46 ` Michael Eager
2018-02-26 7:56 Andrew Guirguis
2018-02-26 8:36 ` Andrew Sadek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE=jbAOsht1g3EDCZeaqZ7A3JnVvziN-0AcZTOMTseq5sogW5Q@mail.gmail.com' \
--to=andrew.sadek.se@gmail.com \
--cc=eager@eagerm.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).