Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Andrew Sadek <andrew dot sadek dot se at gmail dot com>]

On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager <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'.

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.se@gmail.com
>> <mailto:andrew.sadek.se@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 <eager@eagerm.com
>>     <mailto:eager@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 eager@eagerm.com <mailto:
>> eager@eagerm.com>
>>         1960 Park Blvd., Palo Alto, CA 94306
>>
>>
>>
>>
>>     --
>>     Andrew
>>
>>
>>
>>
>> --
>>
>> Andrew
>>
>
> --
> Michael Eager    eager@eagerm.com
> 1960 Park Blvd., Palo Alto, CA 94306
>



-- 

Andrew