On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager <ea...@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'.
Here are the results below:
*Without Patch:*
=== gcc Summary ===
# of expected passes 90776
# of unexpected failures 1317
# of unexpected successes 3
# of expected failures 207
# of unresolved testcases 115
# of unsupported tests 2828
*With Patch and after adding my test case:*
=== gcc Summary ===
# of expected passes 90790
# of unexpected failures 1317
# of unexpected successes 3
# of expected failures 207
# of unresolved testcases 115
# of unsupported tests 2828
Most of failures are in gcc.dg/pch folder => 'undefined reference main',
and in 'gcc.dg/torture/stackalign/' folder => 'undefined reference to
`_GLOBAL_OFFSET_TABLE_'
Please tell me if testing is on the right track and if any further
adaptations are needed.
Thanks.
>
>
>>
>> On Tue, Feb 27, 2018 at 10:13 AM, Andrew Sadek <andrew.sadek...@gmail.com
>> <mailto:andrew.sadek...@gmail.com>> wrote:
>>
>> Thanks Micheal for your response.
>> I shall re-submit patches separately after re-running the whole GCC
>> Test suite and re-checking code conventions.
>> For sending to gdb-patches, it was a conflict from my side as
>> actually I thought it is also for binutils.
>>
>> On Tue, Feb 27, 2018 at 2:07 AM, Michael Eager <ea...@eagerm.com
>> <mailto:ea...@eagerm.com>> wrote:
>>
>> On 02/25/2018 11:44 PM, Andrew Guirguis wrote:
>>
>> Dears,
>>
>> Kindly find attached the patch bundle for Microblaze
>> '-mpic-data-text-relative' feature.
>>
>> Description of the feature in the following link:
>> https://github.com/andrewsadek/microblaze-pic-data-text-rel/
>> blob/pic_data_text_rel/README.md
>> <https://github.com/andrewsadek/microblaze-pic-data-text-
>> rel/blob/pic_data_text_rel/README.md>
>> <https://github.com/andrewsadek/microblaze-pic-data-text-
>> rel/blob/pic_data_text_rel/README.md
>> <https://github.com/andrewsadek/microblaze-pic-data-text-
>> rel/blob/pic_data_text_rel/README.md>>
>>
>> Bundle includes:
>> 1) Change logs for GCC, binutils
>> 2) GCC Test results and comparison with the original.
>> 3) New Test case (picdtr.c)
>> 4) The Patches (against current heads)
>>
>>
>> Hi Andrew --
>>
>> Thanks for the submission. I have the following recommendations:
>>
>> Submit each patch to the appropriate project mailing list. Only
>> submit
>> the patch for the specific project, without patches for other
>> projects.
>>
>> Include a description of the changes with each patch as well as
>> the
>> changelog. Include the patch in your email or as an attachment.
>>
>> It isn't clear why you sent your submission to the gdb-patches
>> mailing
>> list, since there don't appear to be any GDB changes.
>> Conversely, it is
>> not clear why you did not include the binutils mailing list,
>> since you
>> include a patch to that project.
>>
>> Be sure to follow GNU coding conventions, Check brace placement,
>> indent, maximum line length, if statements, etc. I noticed a
>> number
>> of places where these conventions are not followed in your
>> patches.
>>
>> GCC regression tests should include all tests (e.g., gcc.dg),
>> not just the limited number of MicroBlaze-specific tests.
>>
>> -- Michael Eager ea...@eagerm.com <mailto:
>> ea...@eagerm.com>
>> 1960 Park Blvd., Palo Alto, CA 94306
>>
>>
>>
>>
>> --
>> Andrew
>>
>>
>>
>>
>> --
>>
>> Andrew
>>
>
> --
> Michael Eager ea...@eagerm.com
> 1960 Park Blvd., Palo Alto, CA 94306
>
--
Andrew
