Re: Potential SIS or RTEMS/libbsd problem
On 6/3/19 4:14 AM, Chris Johns wrote: > On 1/6/19 6:58 am, Jiri Gaisler wrote: >> I have pushed a small patch to fix some build problems on Cygwin and >> FreeBSD. I don't know how fast we want to progress, but I could prepare a >> patch for RSB to use the new sis repository and skip the sis patches for >> gdb. I guess this would also have include updating any documentation that >> refers to the old sis ... > I am happy to move to using a separate sis executable built by the RSB and for > the gdb versions and patches to stop being maintained. OK, I will look at this on some rainy day ... > > By the way have you looked at the GDB pipe interface to the a remote > executable? > It would be interesting to know how using that transport effects the ^C issue > on > Windows. I will check this. However, I thought pipes were unidirectional on linux...? Jiri. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Build FreeBSD: FAILED 6/rtems-x86_64.bset on x86_64-freebsd12.0 (x86_64-rtems6-gdb-ff4a4474eb-x86_64-freebsd12.0-1)
On 03/06/2019 07:17, Sebastian Huber wrote: On 03/06/2019 04:18, Chris Johns wrote: On 31/5/19 8:11 pm, Sebastian Huber wrote: All the builds on FreeBSD 12 failed this week. The reason seems to be this: grep -r ORIGINAL_AS_FOR_TARGET . ./gcc/config.log:ORIGINAL_AS_FOR_TARGET='' ./gcc/config.status:S["ORIGINAL_AS_FOR_TARGET"]="" ./gcc/as:ORIGINAL_AS_FOR_TARGET="" ./gcc/as: original=$ORIGINAL_AS_FOR_TARGET ./gcc/collect-ld:ORIGINAL_AS_FOR_TARGET="" ./gcc/collect-ld: original=$ORIGINAL_AS_FOR_TARGET ./gcc/nm:ORIGINAL_AS_FOR_TARGET="" ./gcc/nm: original=$ORIGINAL_AS_FOR_TARGET ./gcc/Makefile:ORIGINAL_AS_FOR_TARGET = I don't know why this variable is empty. What does a Linux build show? I wonder if there is a Linux specific change introduced, for example related to sed, shell etc. I use the GNU sed to build GCC on Freebsd. On Linux it looks like: grep -r ORIGINAL_AS_FOR_TARGET . ./gcc/Makefile:ORIGINAL_AS_FOR_TARGET = /scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as ./gcc/nm:ORIGINAL_AS_FOR_TARGET="/scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as" ./gcc/nm: original=$ORIGINAL_AS_FOR_TARGET ./gcc/collect-ld:ORIGINAL_AS_FOR_TARGET="/scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as" ./gcc/collect-ld: original=$ORIGINAL_AS_FOR_TARGET ./gcc/as:ORIGINAL_AS_FOR_TARGET="/scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as" ./gcc/as: original=$ORIGINAL_AS_FOR_TARGET ./gcc/config.status:S["ORIGINAL_AS_FOR_TARGET"]="/scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as" ./gcc/config.log:ORIGINAL_AS_FOR_TARGET='/scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as' If it is still broken in one week, then I will start a git bisect. It was not a GCC build issue: building: aarch64-rtems6-gdb-4f6d070adb-x86_64-freebsd12.0-1 error: building aarch64-rtems6-gdb-4f6d070adb-x86_64-freebsd12.0-1 Build FAILED See error report: rsb-report-aarch64-rtems6-gdb-4f6d070adb-x86_64-freebsd12.0-1.txt error: building aarch64-rtems6-gdb-4f6d070adb-x86_64-freebsd12.0-1 config: tools/rtems-binutils-head.cfg package: aarch64-rtems6-binutils-4f6d070adb-x86_64-freebsd12.0-1 building: aarch64-rtems6-binutils-4f6d070adb-x86_64-freebsd12.0-1 error: building aarch64-rtems6-binutils-4f6d070adb-x86_64-freebsd12.0-1 Build FAILED See error report: rsb-report-aarch64-rtems6-binutils-4f6d070adb-x86_64-freebsd12.0-1.txt error: building aarch64-rtems6-binutils-4f6d070adb-x86_64-freebsd12.0-1 config: tools/rtems-gcc-head-newlib-head.cfg package: aarch64-rtems6-gcc-0f4558599b9-newlib-d5daede26-x86_64-freebsd12.0-1 download: https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/0f4558599b9 -> sources/gnu-mirror-gcc-0f4558599b9.tar.gz RSB continued with the build set even though some steps failed because I used --keep-going. https://www.sourceware.org/ml/binutils/2019-06/msg8.html -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Add Test suite for inttypes.h (psxinttypes.exe) in testsuites/psxtests
On Sat, Jun 1, 2019 at 10:22 PM Gedare Bloom wrote: > > > > On Sat, Jun 1, 2019, 8:29 AM Aditya Upadhyay wrote: >> >> On Sat, Jun 1, 2019 at 5:03 AM Gedare Bloom wrote: >> > >> > On Fri, May 31, 2019 at 10:17 AM Aditya Upadhyay >> > wrote: >> > > >> > > Hi VARoDeK, >> > > >> > > This looks fine to me. I would love to see other's responses. >> > > >> > >> > This test is not right, it needs to be rethought. Let me know if you >> > need further guidance. >> > >> Yeah, Gedare !! I need some further guidance. I had written this test >> 1 year ago, but could not send it on devel. >> I was writing this testsuite for the very first time. > > > If you wrote the test, your name should belong in the copyright info. > I had handed over this code to Vaibhav for sake of learning purposes. If Community does not allow this, Then I would take it back. I would appreciate your thought on that. >> Could you please point me an example? > > > Which psxtest was this derived from? Is there a psxtest that considers string > conversions? That would be a good start. Do some digging. > Thanks for pointing it out. Though I am working on a needed correction. Would It be a wise choice to test cases for each inttypes methods? > The logic of the test needs to be thought out. What is the expected behavior > being tested? How do you isolate correct/incorrect behavior? > I had used hardcoded input only for the success of the operation. I will also consider the expected behavior for Invalid inputs. > Gedare > >> Although I have gone through >> open group POSIX >> Page and looked into some previously made testsuites in the psxtests >> directory. >> >> While configuring, I had used --enable-tests=yes option, but I do not >> see any generated .exe file. >> or Can we generate the .exe file manually? >> >> >> > > On Thu, May 30, 2019 at 8:47 PM VARoDeK wrote: >> > > > >> > > > --- >> > > > testsuites/psxtests/Makefile.am | 7 + >> > > > testsuites/psxtests/configure.ac | 1 + >> > > > testsuites/psxtests/psxinttypes01/init.c | 154 ++ >> > > > .../psxtests/psxinttypes01/psxinttypes01.doc | 57 +++ >> > > > .../psxtests/psxinttypes01/psxinttypes01.scn | 28 >> > > > 5 files changed, 247 insertions(+) >> > > > create mode 100644 testsuites/psxtests/psxinttypes01/init.c >> > > > create mode 100644 testsuites/psxtests/psxinttypes01/psxinttypes01.doc >> > > > create mode 100644 testsuites/psxtests/psxinttypes01/psxinttypes01.scn >> > > > >> > > > diff --git a/testsuites/psxtests/Makefile.am >> > > > b/testsuites/psxtests/Makefile.am >> > > > index 749258cc0c..f619dd9ae9 100644 >> > > > --- a/testsuites/psxtests/Makefile.am >> > > > +++ b/testsuites/psxtests/Makefile.am >> > > > @@ -22,6 +22,13 @@ psx01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psx01) >> > > > \ >> > > > $(support_includes) -I$(top_srcdir)/include >> > > > endif >> > > > >> > > > +if TEST_psxinttypes01 >> > > > +psx_tests += psxinttypes01 >> > > > +psxinttypes01_SOURCES = psxinttypes01/init.c >> > > > +psxinttypes01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxinttypes01) \ >> > > > + $(support_includes) >> > > > +endif >> > > > + >> > > > if HAS_POSIX >> > > > if TEST_psx02 >> > > > psx_tests += psx02 >> > > > diff --git a/testsuites/psxtests/configure.ac >> > > > b/testsuites/psxtests/configure.ac >> > > > index cdd6ee7e4e..e032a6f5ec 100644 >> > > > --- a/testsuites/psxtests/configure.ac >> > > > +++ b/testsuites/psxtests/configure.ac >> > > > @@ -140,6 +140,7 @@ RTEMS_TEST_CHECK([psxtimes01]) >> > > > RTEMS_TEST_CHECK([psxualarm]) >> > > > RTEMS_TEST_CHECK([psxusleep]) >> > > > RTEMS_TEST_CHECK([lib_a]) >> > > > +RTEMS_TEST_CHECK([psxinttypes01]) >> > > > >> > > > AC_CONFIG_FILES([Makefile]) >> > > > AC_OUTPUT >> > > > diff --git a/testsuites/psxtests/psxinttypes01/init.c >> > > > b/testsuites/psxtests/psxinttypes01/init.c >> > > > new file mode 100644 >> > > > index 00..1c6340afe2 >> > > > --- /dev/null >> > > > +++ b/testsuites/psxtests/psxinttypes01/init.c >> > > > @@ -0,0 +1,154 @@ >> > > > +/** >> > > > + * @file >> > > > + * @brief Test suite for inttypes.h methods >> > > > + */ >> > > > + >> > > > +/* >> > > > + * SPDX-License-Identifier: BSD-2-Clause >> > > > + * >> > > > + * Copyright (C) 2019, Vaibhav Gupta >> > > > + * >> > > > + * Redistribution and use in source and binary forms, with or without >> > > > + * modification, are permitted provided that the following conditions >> > > > + * are met: >> > > > + * 1. Redistributions of source code must retain the above copyright >> > > > + *notice, this list of conditions and the following disclaimer. >> > > > + * 2. Redistributions in binary form must reproduce the above >> > > > copyright >> > > > + *notice, this list of conditions and the following disclaimer in >> > > > the >> > > > + *documentation and/or other materials provided with the >> > > > distribution. >> > > > + * >> > > > + * THIS SOFT
GSoC19 location of the PRU drivers
Hi, I will now start coding and porting the PRU drivers to RTEMS. My intention is to put the drivers @rtems/bsps/arm/beagle/pruss, since the beagles are the only boards supporting rtems and having an AM35xx SoC. The drivers should support PRUSS-v1 and -v2, these units can be found on Texas Instruments AM18xx and AM 35xx SoCs. If there are any concerns regarding this decision please let me know, otherwise I will proceed as described. Best, Nils ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: How important is Cygwin support for host tools?
I don’t know anyone that currently uses Cygwin for RTEMS development. The projects I am aware of use Linux and Linux virtual machines. At home I have been able to build RTEMS toolchains and build RTEMS using WSL, so I would use WSL before picking up Cygwin again. WSL 2.0 is supposed to improve speed and compatibility by using a real Linux kernel. Alan On 5/30/19, 8:42 AM, "devel on behalf of Jiri Gaisler" wrote: Does anyone still use Cygwin for RTEMS development? The reason I ask is that I have some portability issues for sis (no async I/O on sockets in Cygwin) and I would like to avoid some ugly workarounds if possible. In the age of virtualization and even WSL in Win 10, do we still need Cygwin ...? Jiri. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Add Test suite for inttypes.h (psxinttypes.exe) in testsuites/psxtests
On Mon, Jun 3, 2019 at 8:37 AM Aditya Upadhyay wrote: > > On Sat, Jun 1, 2019 at 10:22 PM Gedare Bloom wrote: > > > > > > > > On Sat, Jun 1, 2019, 8:29 AM Aditya Upadhyay wrote: > >> > >> On Sat, Jun 1, 2019 at 5:03 AM Gedare Bloom wrote: > >> > > >> > On Fri, May 31, 2019 at 10:17 AM Aditya Upadhyay > >> > wrote: > >> > > > >> > > Hi VARoDeK, > >> > > > >> > > This looks fine to me. I would love to see other's responses. > >> > > > >> > > >> > This test is not right, it needs to be rethought. Let me know if you > >> > need further guidance. > >> > > >> Yeah, Gedare !! I need some further guidance. I had written this test > >> 1 year ago, but could not send it on devel. > >> I was writing this testsuite for the very first time. > > > > > > If you wrote the test, your name should belong in the copyright info. > > > I had handed over this code to Vaibhav for sake of learning purposes. > If Community > does not allow this, Then I would take it back. I would appreciate > your thought on that. > It is perfectly acceptable (and normal) for a student to carry-on with someone else's code, but the original author's contribution (and copyright) need to be maintained. Usually, what we prefer is to have a commit with the original author's code, and then additional commits to change it as needed. > >> Could you please point me an example? > > > > > > Which psxtest was this derived from? Is there a psxtest that considers > > string conversions? That would be a good start. Do some digging. > > > Thanks for pointing it out. Though I am working on a needed > correction. Would It be a wise choice to test cases > for each inttypes methods? > > > The logic of the test needs to be thought out. What is the expected > > behavior being tested? How do you isolate correct/incorrect behavior? > > > I had used hardcoded input only for the success of the operation. I > will also consider the expected behavior for Invalid inputs. > > > Gedare > > > >> Although I have gone through > >> open group POSIX > >> Page and looked into some previously made testsuites in the psxtests > >> directory. > >> > >> While configuring, I had used --enable-tests=yes option, but I do not > >> see any generated .exe file. > >> or Can we generate the .exe file manually? > >> > >> > >> > > On Thu, May 30, 2019 at 8:47 PM VARoDeK > >> > > wrote: > >> > > > > >> > > > --- > >> > > > testsuites/psxtests/Makefile.am | 7 + > >> > > > testsuites/psxtests/configure.ac | 1 + > >> > > > testsuites/psxtests/psxinttypes01/init.c | 154 > >> > > > ++ > >> > > > .../psxtests/psxinttypes01/psxinttypes01.doc | 57 +++ > >> > > > .../psxtests/psxinttypes01/psxinttypes01.scn | 28 > >> > > > 5 files changed, 247 insertions(+) > >> > > > create mode 100644 testsuites/psxtests/psxinttypes01/init.c > >> > > > create mode 100644 > >> > > > testsuites/psxtests/psxinttypes01/psxinttypes01.doc > >> > > > create mode 100644 > >> > > > testsuites/psxtests/psxinttypes01/psxinttypes01.scn > >> > > > > >> > > > diff --git a/testsuites/psxtests/Makefile.am > >> > > > b/testsuites/psxtests/Makefile.am > >> > > > index 749258cc0c..f619dd9ae9 100644 > >> > > > --- a/testsuites/psxtests/Makefile.am > >> > > > +++ b/testsuites/psxtests/Makefile.am > >> > > > @@ -22,6 +22,13 @@ psx01_CPPFLAGS = $(AM_CPPFLAGS) > >> > > > $(TEST_FLAGS_psx01) \ > >> > > > $(support_includes) -I$(top_srcdir)/include > >> > > > endif > >> > > > > >> > > > +if TEST_psxinttypes01 > >> > > > +psx_tests += psxinttypes01 > >> > > > +psxinttypes01_SOURCES = psxinttypes01/init.c > >> > > > +psxinttypes01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxinttypes01) > >> > > > \ > >> > > > + $(support_includes) > >> > > > +endif > >> > > > + > >> > > > if HAS_POSIX > >> > > > if TEST_psx02 > >> > > > psx_tests += psx02 > >> > > > diff --git a/testsuites/psxtests/configure.ac > >> > > > b/testsuites/psxtests/configure.ac > >> > > > index cdd6ee7e4e..e032a6f5ec 100644 > >> > > > --- a/testsuites/psxtests/configure.ac > >> > > > +++ b/testsuites/psxtests/configure.ac > >> > > > @@ -140,6 +140,7 @@ RTEMS_TEST_CHECK([psxtimes01]) > >> > > > RTEMS_TEST_CHECK([psxualarm]) > >> > > > RTEMS_TEST_CHECK([psxusleep]) > >> > > > RTEMS_TEST_CHECK([lib_a]) > >> > > > +RTEMS_TEST_CHECK([psxinttypes01]) > >> > > > > >> > > > AC_CONFIG_FILES([Makefile]) > >> > > > AC_OUTPUT > >> > > > diff --git a/testsuites/psxtests/psxinttypes01/init.c > >> > > > b/testsuites/psxtests/psxinttypes01/init.c > >> > > > new file mode 100644 > >> > > > index 00..1c6340afe2 > >> > > > --- /dev/null > >> > > > +++ b/testsuites/psxtests/psxinttypes01/init.c > >> > > > @@ -0,0 +1,154 @@ > >> > > > +/** > >> > > > + * @file > >> > > > + * @brief Test suite for inttypes.h methods > >> > > > + */ > >> > > > + > >> > > > +/* > >> > > > + * SPDX-License-Identifier: BSD-2-Clause > >> > > > + * > >> > > > + * Copyright (C) 2019, Vaibhav Gupta > >> > > > +
Re: GSoC19 location of the PRU drivers
Putting the drivers in the BSP is fine for now. They can be refactored later if another BSP is added that can use them. On Mon, Jun 3, 2019 at 11:02 AM Nils Hölscher wrote: > > Hi, > > I will now start coding and porting the PRU drivers to RTEMS. > My intention is to put the drivers @rtems/bsps/arm/beagle/pruss, > since the beagles are the only boards supporting rtems and having an AM35xx > SoC. > The drivers should support PRUSS-v1 and -v2, these units can be found on > Texas Instruments AM18xx and AM 35xx SoCs. > If there are any concerns regarding this decision please let me know, > otherwise I will proceed as described. > > Best, > Nils > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Potential SIS or RTEMS/libbsd problem
On 3/6/19 5:51 pm, Jiri Gaisler wrote: > > On 6/3/19 4:14 AM, Chris Johns wrote: >> On 1/6/19 6:58 am, Jiri Gaisler wrote: >>> I have pushed a small patch to fix some build problems on Cygwin and >>> FreeBSD. I don't know how fast we want to progress, but I could prepare a >>> patch for RSB to use the new sis repository and skip the sis patches for >>> gdb. I guess this would also have include updating any documentation that >>> refers to the old sis ... >> I am happy to move to using a separate sis executable built by the RSB and >> for >> the gdb versions and patches to stop being maintained. > OK, I will look at this on some rainy day ... >> >> By the way have you looked at the GDB pipe interface to the a remote >> executable? >> It would be interesting to know how using that transport effects the ^C >> issue on >> Windows. > > I will check this. However, I thought pipes were unidirectional on linux...? > It uses the stdin and stdout of the child process for the remote protocol. It means you need to send console output over the remote protocol which could be considered a feature :) See ... https://github.com/RTEMS/sourceware-mirror-binutils-gdb/blob/master/gdb/gdbserver/remote-utils.c#L337 The nice thing about using a pipe is gdb handles the external simulator so you do not need to coordinate two processes. This makes scripting tools like rtems-test simpler. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RSB SPARC gdb 8.2.1 Build Issue on MSYS2 (64-bit)
Hi I was trying to build the sparc tools on MSYS2 today. SIS was enabled by default and failed to build. Is it expected to build? Is it supposed to be disabled and the host is not properly detected by the RSB? Not sure which way to push on the fix. Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Build FreeBSD: FAILED 6/rtems-x86_64.bset on x86_64-freebsd12.0 (x86_64-rtems6-gdb-ff4a4474eb-x86_64-freebsd12.0-1)
On Mon, Jun 3, 2019 at 4:12 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > > > On 03/06/2019 07:17, Sebastian Huber wrote: > > On 03/06/2019 04:18, Chris Johns wrote: > >> On 31/5/19 8:11 pm, Sebastian Huber wrote: > >>> All the builds on FreeBSD 12 failed this week. The reason seems to > >>> be this: > >>> > >>> grep -r ORIGINAL_AS_FOR_TARGET . > >>> ./gcc/config.log:ORIGINAL_AS_FOR_TARGET='' > >>> ./gcc/config.status:S["ORIGINAL_AS_FOR_TARGET"]="" > >>> ./gcc/as:ORIGINAL_AS_FOR_TARGET="" > >>> ./gcc/as:original=$ORIGINAL_AS_FOR_TARGET > >>> ./gcc/collect-ld:ORIGINAL_AS_FOR_TARGET="" > >>> ./gcc/collect-ld:original=$ORIGINAL_AS_FOR_TARGET > >>> ./gcc/nm:ORIGINAL_AS_FOR_TARGET="" > >>> ./gcc/nm:original=$ORIGINAL_AS_FOR_TARGET > >>> ./gcc/Makefile:ORIGINAL_AS_FOR_TARGET = > >>> > >>> I don't know why this variable is empty. > >>> > >> What does a Linux build show? I wonder if there is a Linux specific > >> change > >> introduced, for example related to sed, shell etc. > > > > I use the GNU sed to build GCC on Freebsd. On Linux it looks like: > > > > grep -r ORIGINAL_AS_FOR_TARGET . > > ./gcc/Makefile:ORIGINAL_AS_FOR_TARGET = > > > /scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as > > > ./gcc/nm:ORIGINAL_AS_FOR_TARGET="/scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as" > > > > > ./gcc/nm:original=$ORIGINAL_AS_FOR_TARGET > > > ./gcc/collect-ld:ORIGINAL_AS_FOR_TARGET="/scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as" > > > > > ./gcc/collect-ld:original=$ORIGINAL_AS_FOR_TARGET > > > ./gcc/as:ORIGINAL_AS_FOR_TARGET="/scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as" > > > > > ./gcc/as:original=$ORIGINAL_AS_FOR_TARGET > > > ./gcc/config.status:S["ORIGINAL_AS_FOR_TARGET"]="/scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as" > > > > > > ./gcc/config.log:ORIGINAL_AS_FOR_TARGET='/scratch/git-rtems-source-builder/rtems/build/tmp/sb-sebastian_h/6/rtems-aarch64.bset/opt/rtems/5/bin/aarch64-rtems6-as' > > > > > > > If it is still broken in one week, then I will start a git bisect. > > > > It was not a GCC build issue: > > building: aarch64-rtems6-gdb-4f6d070adb-x86_64-freebsd12.0-1 > error: building aarch64-rtems6-gdb-4f6d070adb-x86_64-freebsd12.0-1 > Build FAILED >See error report: > rsb-report-aarch64-rtems6-gdb-4f6d070adb-x86_64-freebsd12.0-1.txt > error: building aarch64-rtems6-gdb-4f6d070adb-x86_64-freebsd12.0-1 > config: tools/rtems-binutils-head.cfg > package: aarch64-rtems6-binutils-4f6d070adb-x86_64-freebsd12.0-1 > building: aarch64-rtems6-binutils-4f6d070adb-x86_64-freebsd12.0-1 > error: building aarch64-rtems6-binutils-4f6d070adb-x86_64-freebsd12.0-1 > Build FAILED >See error report: > rsb-report-aarch64-rtems6-binutils-4f6d070adb-x86_64-freebsd12.0-1.txt > error: building aarch64-rtems6-binutils-4f6d070adb-x86_64-freebsd12.0-1 > config: tools/rtems-gcc-head-newlib-head.cfg > package: > aarch64-rtems6-gcc-0f4558599b9-newlib-d5daede26-x86_64-freebsd12.0-1 > download: > https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/0f4558599b9 -> > sources/gnu-mirror-gcc-0f4558599b9.tar.gz > > RSB continued with the build set even though some steps failed because I > used --keep-going. > > https://www.sourceware.org/ml/binutils/2019-06/msg8.html I started a build sweep on Linux this morning which has finished. Looks like it is OK on Linux which is not a huge surprise. I've been following the CTF thread and it is ironic that it wouldn't build on Solaris since the submission is from Oracle people. --joel > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Add Test suite for inttypes.h (psxinttypes.exe) in testsuites/psxtests
On Tue, 4 Jun, 2019, 2:02 AM Gedare Bloom, wrote: > On Mon, Jun 3, 2019 at 8:37 AM Aditya Upadhyay > wrote: > > > > On Sat, Jun 1, 2019 at 10:22 PM Gedare Bloom wrote: > > > > > > > > > > > > On Sat, Jun 1, 2019, 8:29 AM Aditya Upadhyay > wrote: > > >> > > >> On Sat, Jun 1, 2019 at 5:03 AM Gedare Bloom wrote: > > >> > > > >> > On Fri, May 31, 2019 at 10:17 AM Aditya Upadhyay < > aadit0...@gmail.com> wrote: > > >> > > > > >> > > Hi VARoDeK, > > >> > > > > >> > > This looks fine to me. I would love to see other's responses. > > >> > > > > >> > > > >> > This test is not right, it needs to be rethought. Let me know if you > > >> > need further guidance. > > >> > > > >> Yeah, Gedare !! I need some further guidance. I had written this test > > >> 1 year ago, but could not send it on devel. > > >> I was writing this testsuite for the very first time. > > > > > > > > > If you wrote the test, your name should belong in the copyright info. > > > > > I had handed over this code to Vaibhav for sake of learning purposes. > > If Community > > does not allow this, Then I would take it back. I would appreciate > > your thought on that. > > > > It is perfectly acceptable (and normal) for a student to carry-on with > someone else's code, but the original author's contribution (and > copyright) need to be maintained. Usually, what we prefer is to have > a commit with the original author's code, and then additional commits > to change it as needed. > Yes, actually we discussed about same, and then he asked me to add my name as i was going to send it to devel. Things were new for me too. I will put his name only now on copyright info. > > > >> Could you please point me an example? > > > > > > > > > Which psxtest was this derived from? Is there a psxtest that considers > string conversions? That would be a good start. Do some digging. > > > > > Thanks for pointing it out. Though I am working on a needed > > correction. Would It be a wise choice to test cases > > for each inttypes methods? > > > > > The logic of the test needs to be thought out. What is the expected > behavior being tested? How do you isolate correct/incorrect behavior? > > > > > I had used hardcoded input only for the success of the operation. I > > will also consider the expected behavior for Invalid inputs. > > > > > Gedare > > > > > >> Although I have gone through > > >> open group POSIX > > >> Page and looked into some previously made testsuites in the psxtests > directory. > > >> > > >> While configuring, I had used --enable-tests=yes option, but I do not > > >> see any generated .exe file. > > >> or Can we generate the .exe file manually? > > >> > > >> > > >> > > On Thu, May 30, 2019 at 8:47 PM VARoDeK > wrote: > > >> > > > > > >> > > > --- > > >> > > > testsuites/psxtests/Makefile.am | 7 + > > >> > > > testsuites/psxtests/configure.ac | 1 + > > >> > > > testsuites/psxtests/psxinttypes01/init.c | 154 > ++ > > >> > > > .../psxtests/psxinttypes01/psxinttypes01.doc | 57 +++ > > >> > > > .../psxtests/psxinttypes01/psxinttypes01.scn | 28 > > >> > > > 5 files changed, 247 insertions(+) > > >> > > > create mode 100644 testsuites/psxtests/psxinttypes01/init.c > > >> > > > create mode 100644 > testsuites/psxtests/psxinttypes01/psxinttypes01.doc > > >> > > > create mode 100644 > testsuites/psxtests/psxinttypes01/psxinttypes01.scn > > >> > > > > > >> > > > diff --git a/testsuites/psxtests/Makefile.am > b/testsuites/psxtests/Makefile.am > > >> > > > index 749258cc0c..f619dd9ae9 100644 > > >> > > > --- a/testsuites/psxtests/Makefile.am > > >> > > > +++ b/testsuites/psxtests/Makefile.am > > >> > > > @@ -22,6 +22,13 @@ psx01_CPPFLAGS = $(AM_CPPFLAGS) > $(TEST_FLAGS_psx01) \ > > >> > > > $(support_includes) -I$(top_srcdir)/include > > >> > > > endif > > >> > > > > > >> > > > +if TEST_psxinttypes01 > > >> > > > +psx_tests += psxinttypes01 > > >> > > > +psxinttypes01_SOURCES = psxinttypes01/init.c > > >> > > > +psxinttypes01_CPPFLAGS = $(AM_CPPFLAGS) > $(TEST_FLAGS_psxinttypes01) \ > > >> > > > + $(support_includes) > > >> > > > +endif > > >> > > > + > > >> > > > if HAS_POSIX > > >> > > > if TEST_psx02 > > >> > > > psx_tests += psx02 > > >> > > > diff --git a/testsuites/psxtests/configure.ac > b/testsuites/psxtests/configure.ac > > >> > > > index cdd6ee7e4e..e032a6f5ec 100644 > > >> > > > --- a/testsuites/psxtests/configure.ac > > >> > > > +++ b/testsuites/psxtests/configure.ac > > >> > > > @@ -140,6 +140,7 @@ RTEMS_TEST_CHECK([psxtimes01]) > > >> > > > RTEMS_TEST_CHECK([psxualarm]) > > >> > > > RTEMS_TEST_CHECK([psxusleep]) > > >> > > > RTEMS_TEST_CHECK([lib_a]) > > >> > > > +RTEMS_TEST_CHECK([psxinttypes01]) > > >> > > > > > >> > > > AC_CONFIG_FILES([Makefile]) > > >> > > > AC_OUTPUT > > >> > > > diff --git a/testsuites/psxtests/psxinttypes01/init.c > b/testsuites/psxtests/psxinttypes01/init.c > > >> > > > new file mode 100644 > > >> > > > index 00..1c6340afe
