Re: [PATCH 0/5] Fix gcc 12 warnings

2022-06-08 Thread Chris Johns
Thank you for posting fixes for these warnings.

I opened https://devel.rtems.org/ticket/4662 to track this issue. Can the commit
messages please be updated to includes "Updates #4662".

Thanks
Chris

On 8/6/2022 11:34 pm, Matthew Joyce wrote:
> From: Matt Joyce 
> 
> Hello,
> 
> These patches fix several new warnings which appeared with
> gcc 12.
> 
> Sincerely,
> 
> Matt
> 
> Matt Joyce (5):
>   libcsupport/src/__times.c: fix warning
>   cpukit/posix/src/_execve.c: fix warning
>   cpukit/libmd/md5.c: fix warning
>   testsuites/libtests/POSIX/free.c: fix warning
>   testsuites/libtests/malloctest: fix warning
> 
>  cpukit/libcsupport/src/__times.c  |  5 +
>  cpukit/libmd/md5.c|  2 +-
>  cpukit/posix/src/_execve.c|  5 +
>  testsuites/libtests/POSIX/free.c  |  2 +-
>  testsuites/libtests/malloctest/init.c | 17 +++--
>  5 files changed, 15 insertions(+), 16 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [gcc] Enable TLS support for RTEMS in libstdc++

2022-06-08 Thread Chris Johns
On 9/6/2022 12:18 am, Sebastian Huber wrote:
> On 08/06/2022 16:11, Joel Sherrill wrote:
>> On Wed, Jun 8, 2022 at 8:47 AM Sebastian Huber
>> > > wrote:
>> If we are to maintain a thread safe C Library, then we have to be
>> sure TLS is always supported or we have to have a fallback
>> method.
> 
> The fallback method for C++ is only thread safe if you have enough POSIX keys
> configured.

This is an important point. When I wrote the exit03 test it passed with the
confdefs config from exit01m iw no POSIX keys. After I added 2 POSIX keys the
test failed as I expected it to.

Currently there is no way to check or inform a user the POSIX key create as
failed. I think there is a gcc ticket on this topic I raised a while ago.

FWIW Jonathan Wakely has a fix for the issue I am seeing with the eh_globals
(used when there is no TLS) support but it does have a corner case when exit()
is called the POSIX key has been deleted so exceptions revert to single 
threaded.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH] validation: Fix CallWithinISR()

2022-06-08 Thread Gedare Bloom
On Wed, Jun 8, 2022 at 1:04 PM Sebastian Huber
 wrote:
>
> On 08/06/2022 17:40, Gedare Bloom wrote:
> > Hm. This looks ok, but it also seems to be a bit of an awkward
> > requirement. Is this only relevant for the tm27 test?
>
> I hijacked the tm27 support to add an API for software interrupts.
>
Do we need something more formal?

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] validation: Fix CallWithinISR()

2022-06-08 Thread Sebastian Huber

On 08/06/2022 17:40, Gedare Bloom wrote:

Hm. This looks ok, but it also seems to be a bit of an awkward
requirement. Is this only relevant for the tm27 test?


I hijacked the tm27 support to add an API for software interrupts.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/5] cpukit/libmd/md5.c: fix warning

2022-06-08 Thread Joel Sherrill
On Wed, Jun 8, 2022, 10:45 AM Gedare Bloom  wrote:

> Does this code have an upstream?
>

I tried to find it. Maybe whoever added it has memory of the source.

As best I can tell, it is lightly or not maintained reference code.



> On Wed, Jun 8, 2022 at 7:35 AM Matthew Joyce
>  wrote:
> >
> > From: Matt Joyce 
> >
> > Specify array size in parameter to match function prototype. This
> > fixes a new warning in gcc 12.
> > ---
> >  cpukit/libmd/md5.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/cpukit/libmd/md5.c b/cpukit/libmd/md5.c
> > index 4c909f37a0..5e3a100c7b 100644
> > --- a/cpukit/libmd/md5.c
> > +++ b/cpukit/libmd/md5.c
> > @@ -165,7 +165,7 @@ void MD5Update (
> > ends with the desired message digest in mdContext->digest[0...15].
> >   */
> >  void MD5Final (
> > -  unsigned char hash[],
> > +  unsigned char hash[16],
> >MD5_CTX *mdContext )
> >  {
> >UINT4 in[16];
> > --
> > 2.31.1
> >
> > ___
> > 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/5] cpukit/libmd/md5.c: fix warning

2022-06-08 Thread Gedare Bloom
Does this code have an upstream?

On Wed, Jun 8, 2022 at 7:35 AM Matthew Joyce
 wrote:
>
> From: Matt Joyce 
>
> Specify array size in parameter to match function prototype. This
> fixes a new warning in gcc 12.
> ---
>  cpukit/libmd/md5.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/libmd/md5.c b/cpukit/libmd/md5.c
> index 4c909f37a0..5e3a100c7b 100644
> --- a/cpukit/libmd/md5.c
> +++ b/cpukit/libmd/md5.c
> @@ -165,7 +165,7 @@ void MD5Update (
> ends with the desired message digest in mdContext->digest[0...15].
>   */
>  void MD5Final (
> -  unsigned char hash[],
> +  unsigned char hash[16],
>MD5_CTX *mdContext )
>  {
>UINT4 in[16];
> --
> 2.31.1
>
> ___
> 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 1/1] Newlib01: Add tests for rand() and lrand48()

2022-06-08 Thread Gedare Bloom
ok

On Wed, Jun 8, 2022 at 3:02 AM Matthew Joyce
 wrote:
>
> From: Matt Joyce 
>
> Check that the state of rand() and lrand48() is thread-specific,
> that they are properly initialized, and return the expected
> sequence of pseudo-random numbers for default seed values.
> ---
>  testsuites/libtests/newlib01/init.c   | 50 +++
>  testsuites/libtests/newlib01/newlib01.doc |  3 ++
>  2 files changed, 53 insertions(+)
>
> diff --git a/testsuites/libtests/newlib01/init.c 
> b/testsuites/libtests/newlib01/init.c
> index 8975a72fad..0bb3c4628b 100644
> --- a/testsuites/libtests/newlib01/init.c
> +++ b/testsuites/libtests/newlib01/init.c
> @@ -82,6 +82,50 @@ static void wait(void)
>rtems_test_assert(sc == RTEMS_SUCCESSFUL);
>  }
>
> +/*
> + * Check that rand() is properly initialized and returns the expected 
> sequence
> + * for default seed values. A call to rand() without any previous call to
> + * srand() generates the same sequence as when srand() is first called with a
> + * seed value of 1.
> + */
> +static void test_rand(void)
> +{
> +  int rv;
> +
> +  rv = rand();
> +  rtems_test_assert(rv == 1481765933);
> +  rv = rand();
> +  rtems_test_assert(rv == 1085377743);
> +  rv = rand();
> +  rtems_test_assert(rv == 1270216262);
> +
> +  srand(1);
> +  rv = rand();
> +  rtems_test_assert(rv == 1481765933);
> +  rv = rand();
> +  rtems_test_assert(rv == 1085377743);
> +  rv = rand();
> +  rtems_test_assert(rv == 1270216262);
> +}
> +
> +/*
> + * Check that lrand48() is properly initialized and returns the expected
> + * sequence for default seed values. A call to lrand48() without any previous
> + * call to srand48() uses default constant initializer values set in the 
> _seed
> + * member of struct _rand48.
> + */
> +static void test_lrand48(void)
> +{
> +  long rv;
> +
> +  rv = lrand48();
> +  rtems_test_assert(rv == 851401618);
> +  rv = lrand48();
> +  rtems_test_assert(rv == 1804928587);
> +  rv = lrand48();
> +  rtems_test_assert(rv == 758783491);
> +}
> +
>  static void stdio_file_worker(rtems_task_argument arg)
>  {
>test_context *ctx = _instance;
> @@ -90,6 +134,9 @@ static void stdio_file_worker(rtems_task_argument arg)
>char buf[1] = { 'x' };
>size_t n;
>
> +  test_rand();
> +  test_lrand48();
> +
>rtems_test_assert(reent->__cleanup == NULL);
>
>output = stdout = fopen(_file_path[0], "r+");
> @@ -454,6 +501,9 @@ static void Init(rtems_task_argument arg)
>int rv;
>
>TEST_BEGIN();
> +  test_rand();
> +  test_lrand48();
> +
>ctx->main_task_id = rtems_task_self();
>
>/* Fill dynamic file pool in Newlib */
> diff --git a/testsuites/libtests/newlib01/newlib01.doc 
> b/testsuites/libtests/newlib01/newlib01.doc
> index fbda12aa98..dc16584418 100644
> --- a/testsuites/libtests/newlib01/newlib01.doc
> +++ b/testsuites/libtests/newlib01/newlib01.doc
> @@ -19,3 +19,6 @@ concepts:
>- Check that exit procedures provide proper resource cleanup. Ensure that
>  a file opened from a worker task--but that is not assigned to a stdio
>  stream--is not closed during thread termination.
> +  - Check that the state of random number generators is thread-specific, they
> +are properly initialized, and return the expected sequence for default
> +seed values.
> --
> 2.31.1
>
> ___
> 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] validation: Fix CallWithinISR()

2022-06-08 Thread Gedare Bloom
Hm. This looks ok, but it also seems to be a bit of an awkward
requirement. Is this only relevant for the tm27 test?

On Tue, Jun 7, 2022 at 8:01 AM Sebastian Huber
 wrote:
>
> Some BSPs require that Clear_tm27_intr() is called in the interrupt
> service routine.
>
> Update #3269.
> ---
>  testsuites/validation/tx-call-within-isr.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/testsuites/validation/tx-call-within-isr.c 
> b/testsuites/validation/tx-call-within-isr.c
> index 226647c0bc..3b5d1e139d 100644
> --- a/testsuites/validation/tx-call-within-isr.c
> +++ b/testsuites/validation/tx-call-within-isr.c
> @@ -71,6 +71,8 @@ static void CallWithinISRHandler( rtems_vector_number 
> vector )
>(void) vector;
>ctx = 
>
> +  Clear_tm27_intr();
> +
>while ( true ) {
>  rtems_interrupt_lock_context lock_context;
>  CallWithinISRRequest*request;
> --
> 2.35.3
>
> ___
> 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] testsuite/libtests: Add exit03 to test exit() with C++

2022-06-08 Thread Gedare Bloom
ok

On Tue, Jun 7, 2022 at 10:49 PM  wrote:
>
> From: Chris Johns 
>
> Updates #4661
> ---
>  spec/build/testsuites/libtests/exit03.yml |  20 
>  spec/build/testsuites/libtests/grp.yml|   2 +
>  testsuites/libtests/exit03/exit03.doc |  11 ++
>  testsuites/libtests/exit03/exit03.scn |   5 +
>  testsuites/libtests/exit03/init.c | 122 ++
>  testsuites/libtests/exit03/stdio.cc   |  61 +++
>  6 files changed, 221 insertions(+)
>  create mode 100644 spec/build/testsuites/libtests/exit03.yml
>  create mode 100644 testsuites/libtests/exit03/exit03.doc
>  create mode 100644 testsuites/libtests/exit03/exit03.scn
>  create mode 100644 testsuites/libtests/exit03/init.c
>  create mode 100644 testsuites/libtests/exit03/stdio.cc
>
> diff --git a/spec/build/testsuites/libtests/exit03.yml 
> b/spec/build/testsuites/libtests/exit03.yml
> new file mode 100644
> index 00..d9bd123de0
> --- /dev/null
> +++ b/spec/build/testsuites/libtests/exit03.yml
> @@ -0,0 +1,20 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +build-type: test-program
> +cflags: []
> +copyrights:
> +- Copyright (C) 2022 Chris Johns (Contemporary Software)
> +cppflags: []
> +cxxflags: []
> +enabled-by: true
> +features: c cxx cxxprogram
> +includes: []
> +ldflags: []
> +links: []
> +source:
> +- testsuites/libtests/exit03/init.c
> +- testsuites/libtests/exit03/stdio.cc
> +stlib: []
> +target: testsuites/libtests/exit03.exe
> +type: build
> +use-after: []
> +use-before: []
> diff --git a/spec/build/testsuites/libtests/grp.yml 
> b/spec/build/testsuites/libtests/grp.yml
> index d352c8221c..793e1f3fef 100644
> --- a/spec/build/testsuites/libtests/grp.yml
> +++ b/spec/build/testsuites/libtests/grp.yml
> @@ -113,6 +113,8 @@ links:
>uid: exit01
>  - role: build-dependency
>uid: exit02
> +- role: build-dependency
> +  uid: exit03
>  - role: build-dependency
>uid: fcntl
>  - role: build-dependency
> diff --git a/testsuites/libtests/exit03/exit03.doc 
> b/testsuites/libtests/exit03/exit03.doc
> new file mode 100644
> index 00..c575ef40fb
> --- /dev/null
> +++ b/testsuites/libtests/exit03/exit03.doc
> @@ -0,0 +1,11 @@
> +This file describes the directives and concepts tested by this test set.
> +
> +test set name: exit03
> +
> +directives:
> +
> +  exit()
> +
> +concepts:
> +
> +  Ensure exit() in a C++ application  works.
> diff --git a/testsuites/libtests/exit03/exit03.scn 
> b/testsuites/libtests/exit03/exit03.scn
> new file mode 100644
> index 00..03d45a0c1f
> --- /dev/null
> +++ b/testsuites/libtests/exit03/exit03.scn
> @@ -0,0 +1,5 @@
> +caught exception
> +IO on std::cout
> +IO on std::cerr
> +
> +*** END OF TEST EXIT 3 ***
> diff --git a/testsuites/libtests/exit03/init.c 
> b/testsuites/libtests/exit03/init.c
> new file mode 100644
> index 00..b761c0af4a
> --- /dev/null
> +++ b/testsuites/libtests/exit03/init.c
> @@ -0,0 +1,122 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/*
> + * Copyright (c) 2022 Chris Johns (Contemporary Software).  All rights 
> reserved.
> + * Copyright (c) 2013 embedded brains GmbH.  All rights reserved.
> + *
> + * 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 SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include "tmacros.h"
> +
> +#include 
> +
> +/* Use assert() not rtems_test_assert() since it uses exit() */
> +#include 
> +
> +#include 
> +
> +void cplusplus_stdio(void);
> +
> +const char rtems_test_name[] = "EXIT 3";
> +
> +#define EXIT_STATUS 123
> +
> +static int counter;
> +
> +static void atexit_0(void)
> +{
> +  assert(counter == 0);
> +  ++counter;
> +}
> +
> +static void 

Re: [gcc] Enable TLS support for RTEMS in libstdc++

2022-06-08 Thread Sebastian Huber



On 08/06/2022 16:11, Joel Sherrill wrote:
On Wed, Jun 8, 2022 at 8:47 AM Sebastian Huber 
> wrote:


On 08/06/2022 15:39, Joel Sherrill wrote:
 > Is TLS actually supported on all targets except MIPS?

I only added MIPS since this target has a fundamental issue with the
TLS
support.

Which target would you also exclude?


About half of them.


It seems to be only bfin, lm32, moxie, or1k, and v850. Are these targets 
still in use? Do we have a maintainer for these targets?




arch64 - Yes
arm - Yes
bfin - ?
i386 - Yes
lm32 - ?
m68k - Yes
microblaze - Yes
mips - No
moxie - ?
nios2 -?


nios2 - Yes


or1k - ?
powerpc - Yes
riscv - Probably


riscv - Yes


sh - ?
sparc - Yes
sparc64 - ?
v850 - ?
x86_64 - Likely

I'm not even sure there is a definition of how TLS is implemented
on some of these architectures. Maybe GCC has a generic way of
handling TLS that a port could fall back on, but I am unaware of it.

If we are to maintain a thread safe C Library, then we have to be
sure TLS is always supported or we have to have a fallback
method.


The fallback method for C++ is only thread safe if you have enough POSIX 
keys configured.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [gcc] Enable TLS support for RTEMS in libstdc++

2022-06-08 Thread Joel Sherrill
On Wed, Jun 8, 2022 at 8:47 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/06/2022 15:39, Joel Sherrill wrote:
> > Is TLS actually supported on all targets except MIPS?
>
> I only added MIPS since this target has a fundamental issue with the TLS
> support.
>
> Which target would you also exclude?
>

About half of them.

arch64 - Yes
arm - Yes
bfin - ?
i386 - Yes
lm32 - ?
m68k - Yes
microblaze - Yes
mips - No
moxie - ?
nios2 -?
or1k - ?
powerpc - Yes
riscv - Probably
sh - ?
sparc - Yes
sparc64 - ?
v850 - ?
x86_64 - Likely

I'm not even sure there is a definition of how TLS is implemented
on some of these architectures. Maybe GCC has a generic way of
handling TLS that a port could fall back on, but I am unaware of it.

If we are to maintain a thread safe C Library, then we have to be
sure TLS is always supported or we have to have a fallback
method.


> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [gcc] Enable TLS support for RTEMS in libstdc++

2022-06-08 Thread Sebastian Huber

On 08/06/2022 15:39, Joel Sherrill wrote:

Is TLS actually supported on all targets except MIPS?


I only added MIPS since this target has a fundamental issue with the TLS 
support.


Which target would you also exclude?

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] CONTRIBUTING: Warn about white space changes

2022-06-08 Thread Joel Sherrill
This looks good. I would have said "not reformat code" but that's ok.

--joel

On Wed, Jun 8, 2022 at 7:57 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  CONTRIBUTING.rst | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
> index 79a42db1..36cd91de 100644
> --- a/CONTRIBUTING.rst
> +++ b/CONTRIBUTING.rst
> @@ -279,6 +279,12 @@ original FreeBSD code.
>  Rules for Modifying FreeBSD Source
>  ==
>
> +Do not format original FreeBSD code.  Do not perform white space changes
> even
> +if you get git commit warnings.  **Check your editor settings so that it
> +does not perform white space changes automatically**, for example adding a
> +newline to the end of the file.  White space changes may result in
> conflicts
> +during updates, especially changes at the end of a file.
> +
>  Changes in FreeBSD files must be done using ``__rtems__`` C pre-processor
> guards.
>  This makes synchronization with the FreeBSD upstream easier and is very
>  important.  Patches which do not follow these rules will be rejected.
> Only add
> @@ -380,12 +386,6 @@ In general, provide empty header files and do not
> guard includes.
>  For new code use
>  `STYLE(9) <
> http://www.freebsd.org/cgi/man.cgi?query=style=0=9>`_.
>
> -Do not format original FreeBSD code.  Do not perform white space changes
> even
> -if you get git commit warnings.  Check your editor settings so that it
> doesn't
> -perform white space changes automatically, for example adding a newline
> to the
> -end of the file.  White space changes may result in conflicts during
> updates,
> -especially changes at the end of a file.
> -
>  Automatically Generated FreeBSD Files
>  =
>
> --
> 2.35.3
>
> ___
> 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: [gcc] Enable TLS support for RTEMS in libstdc++

2022-06-08 Thread Joel Sherrill
Is TLS actually supported on all targets except MIPS?

--joel

On Wed, Jun 8, 2022 at 1:51 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> libstdc++-v3/ChangeLog:
>
> * crossconfig.m4 (*-rtems*): Enable TLS support for all RTEMS
> targets
> except mips.
> ---
>  libstdc++-v3/crossconfig.m4 | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
> index ae5283b7ad3..732f6818074 100644
> --- a/libstdc++-v3/crossconfig.m4
> +++ b/libstdc++-v3/crossconfig.m4
> @@ -249,6 +249,13 @@ case "${host}" in
>  GLIBCXX_CHECK_LINKER_FEATURES
>  GLIBCXX_CHECK_MATH_SUPPORT
>  GLIBCXX_CHECK_STDLIB_SUPPORT
> +case "$target" in
> +  mips*-rtems*)
> +;;
> +  *)
> +AC_DEFINE(HAVE_TLS)
> +;;
> +esac
>  ;;
>*-tpf)
>  SECTION_FLAGS='-ffunction-sections -fdata-sections'
> --
> 2.35.3
>
> ___
> 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

[PATCH 3/5] cpukit/libmd/md5.c: fix warning

2022-06-08 Thread Matthew Joyce
From: Matt Joyce 

Specify array size in parameter to match function prototype. This
fixes a new warning in gcc 12.
---
 cpukit/libmd/md5.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmd/md5.c b/cpukit/libmd/md5.c
index 4c909f37a0..5e3a100c7b 100644
--- a/cpukit/libmd/md5.c
+++ b/cpukit/libmd/md5.c
@@ -165,7 +165,7 @@ void MD5Update (
ends with the desired message digest in mdContext->digest[0...15].
  */
 void MD5Final (
-  unsigned char hash[],
+  unsigned char hash[16],
   MD5_CTX *mdContext )
 {
   UINT4 in[16];
-- 
2.31.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH 4/5] testsuites/libtests/POSIX/free.c: fix warning

2022-06-08 Thread Matthew Joyce
From: Matt Joyce 

This change fixes a new warning in gcc 12.
---
 testsuites/libtests/POSIX/free.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuites/libtests/POSIX/free.c b/testsuites/libtests/POSIX/free.c
index 8550eaa85c..6bc961b968 100644
--- a/testsuites/libtests/POSIX/free.c
+++ b/testsuites/libtests/POSIX/free.c
@@ -14,7 +14,7 @@
 
 int main (void)
 {
-  free((void *) 42);
+  free(NULL);
 
   return 0;
 }
-- 
2.31.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH 5/5] testsuites/libtests/malloctest: fix warning

2022-06-08 Thread Matthew Joyce
From: Matt Joyce 

Removed problematic free() and several unnecessary print statement
parameters. This fixes new warnings in gcc 12.
---
 testsuites/libtests/malloctest/init.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/testsuites/libtests/malloctest/init.c 
b/testsuites/libtests/malloctest/init.c
index 05d97a27d5..bf623f9cbe 100644
--- a/testsuites/libtests/malloctest/init.c
+++ b/testsuites/libtests/malloctest/init.c
@@ -60,8 +60,7 @@ static void test_realloc(void)
   for (i=2 ; i<2048 ; i++) {
 p2 = realloc(p1, i);
 if (p2 != p1)
-  printf( "realloc - failed grow in place: "
-  "%p != realloc(%p,%zu)\n", p1, p2, i);
+  printf( "realloc - failed grow in place");
 p1 = p2;
   }
   free(p1);
@@ -71,8 +70,7 @@ static void test_realloc(void)
   for (i=2047 ; i>=1; i--)  {
 p2 = realloc(p1, i);
 if (p2 != p1)
-  printf( "realloc - failed shrink in place: "
-  "%p != realloc(%p,%zu)\n", p1, p2, i);
+  printf( "realloc - failed shrink in place");
 p1 = p2;
   }
   free(p1);
@@ -85,7 +83,7 @@ static void test_realloc(void)
   p3 = realloc(p1, 64);
   if (p3 == p1 || p3 == NULL)
 printf(
-  "realloc - failed non-in place: realloc(%p,%d) = %p\n", p1, 64, p3);
+  "realloc - failed non-in place");
   free(p3);
   free(p2);
 
@@ -118,13 +116,6 @@ static void test_realloc(void)
   malloc_walk_ok = malloc_walk( 1234, false );
   rtems_test_assert( malloc_walk_ok );
   _Thread_Dispatch_enable( _Per_CPU_Get() );
-
-  /*
-   *  Realloc with a bad pointer to force a point
-   */
-  p4 = realloc( test_realloc, 32 );
-
-  p4 = _realloc_r( NULL, NULL, 1 );
 }
 
 #define TEST_HEAP_SIZE 2048
@@ -1526,8 +1517,6 @@ static void test_early_malloc( void )
   rtems_test_assert( p != q );
   rtems_test_assert( q[0] == 0 );
 
-  free( q );
-
   r = realloc( q, 128 );
   rtems_test_assert( r == q );
 
-- 
2.31.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH 1/5] libcsupport/src/__times.c: fix warning

2022-06-08 Thread Matthew Joyce
From: Matt Joyce 

Define _LIBC to access prototype for _times() function. This fixes a
new warning in gcc 12.
---
 cpukit/libcsupport/src/__times.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/cpukit/libcsupport/src/__times.c b/cpukit/libcsupport/src/__times.c
index 629a7bc633..1a994ad953 100644
--- a/cpukit/libcsupport/src/__times.c
+++ b/cpukit/libcsupport/src/__times.c
@@ -42,6 +42,11 @@
  */
 #define _COMPILING_NEWLIB
 
+/*
+ *  Needed to get the prototype for _times()
+ */
+#define _LIBC
+
 #include 
 
 #include 
-- 
2.31.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH 0/5] Fix gcc 12 warnings

2022-06-08 Thread Matthew Joyce
From: Matt Joyce 

Hello,

These patches fix several new warnings which appeared with
gcc 12.

Sincerely,

Matt

Matt Joyce (5):
  libcsupport/src/__times.c: fix warning
  cpukit/posix/src/_execve.c: fix warning
  cpukit/libmd/md5.c: fix warning
  testsuites/libtests/POSIX/free.c: fix warning
  testsuites/libtests/malloctest: fix warning

 cpukit/libcsupport/src/__times.c  |  5 +
 cpukit/libmd/md5.c|  2 +-
 cpukit/posix/src/_execve.c|  5 +
 testsuites/libtests/POSIX/free.c  |  2 +-
 testsuites/libtests/malloctest/init.c | 17 +++--
 5 files changed, 15 insertions(+), 16 deletions(-)

-- 
2.31.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH 2/5] cpukit/posix/src/_execve.c: fix warning

2022-06-08 Thread Matthew Joyce
From: Matt Joyce 

Define _LIBC to access prototype for _execve() function. This fixes a
new warning in gcc 12.
---
 cpukit/posix/src/_execve.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/cpukit/posix/src/_execve.c b/cpukit/posix/src/_execve.c
index 2858d13082..29c4fe8fcf 100644
--- a/cpukit/posix/src/_execve.c
+++ b/cpukit/posix/src/_execve.c
@@ -47,6 +47,11 @@
  */
 #define _COMPILING_NEWLIB
 
+/*
+ *  Needed to get the prototype for _execve()
+ */
+#define _LIBC
+
 #include 
 #include 
 #include 
-- 
2.31.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH] CONTRIBUTING: Warn about white space changes

2022-06-08 Thread Sebastian Huber
---
 CONTRIBUTING.rst | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
index 79a42db1..36cd91de 100644
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -279,6 +279,12 @@ original FreeBSD code.
 Rules for Modifying FreeBSD Source
 ==
 
+Do not format original FreeBSD code.  Do not perform white space changes even
+if you get git commit warnings.  **Check your editor settings so that it
+does not perform white space changes automatically**, for example adding a
+newline to the end of the file.  White space changes may result in conflicts
+during updates, especially changes at the end of a file.
+
 Changes in FreeBSD files must be done using ``__rtems__`` C pre-processor 
guards.
 This makes synchronization with the FreeBSD upstream easier and is very
 important.  Patches which do not follow these rules will be rejected.  Only add
@@ -380,12 +386,6 @@ In general, provide empty header files and do not guard 
includes.
 For new code use
 `STYLE(9) 
`_.
 
-Do not format original FreeBSD code.  Do not perform white space changes even
-if you get git commit warnings.  Check your editor settings so that it doesn't
-perform white space changes automatically, for example adding a newline to the
-end of the file.  White space changes may result in conflicts during updates,
-especially changes at the end of a file.
-
 Automatically Generated FreeBSD Files
 =
 
-- 
2.35.3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH v2] Use global stdio streams for all configurations

2022-06-08 Thread Sebastian Huber

On 08/06/2022 11:43, Sebastian Huber wrote:

The _REENT_GLOBAL_STDIO_STREAMS was introduced by commit
668a4c8722090fffd10869dbb15b879651c1370d in 2017.  Since then it was enabled by
default for RTEMS.  Recently, the option was enabled for Cygwin which
previously used an alternative implementation to use global stdio streams.


Sorry, wrong mailing list.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] Use global stdio streams for all configurations

2022-06-08 Thread Sebastian Huber
The _REENT_GLOBAL_STDIO_STREAMS was introduced by commit
668a4c8722090fffd10869dbb15b879651c1370d in 2017.  Since then it was enabled by
default for RTEMS.  Recently, the option was enabled for Cygwin which
previously used an alternative implementation to use global stdio streams.

In Newlib, the stdio streams are defined to thread-specific pointers
_reent::_stdin, _reent::_stdout and _reent::_stderr.  If the option is disabled
(the default for most systems), then these pointers are initialized to
thread-specific FILE objects which use file descriptors 0, 1, and 2,
respectively.  There are at least three problems with this:

(1) The thread-specific FILE objects are closed by _reclaim_reent().  This
leads to problems with language run-time libraries that provide wrappers to
the C/POSIX stdio streams (for example C++ and Ada), since they use the
thread-specific FILE objects of the initialization thread.  In case the
initialization thread is deleted, then they use freed memory.

(2) Since thread-specific FILE objects are used with a common output device via
file descriptors 0, 1 and 2, the locking at FILE object level cannot ensure
atomicity of the output, e.g. a call to printf().

(3) There are resource managment issues, see:

https://sourceware.org/pipermail/newlib/2022/019558.html

https://bugs.linaro.org/show_bug.cgi?id=5841

This patch enables the _REENT_GLOBAL_STDIO_STREAMS behaviour for all Newlib
configurations and removes the option.  This removes a couple of #ifdef blocks.
---
v2:

* Add missing ';' to _REENT_INIT_PTR_ZEROED().

* Rebase to Newlib master.

 newlib/README |   6 --
 newlib/configure.ac   |  10 +--
 newlib/libc/include/sys/config.h  |   7 --
 newlib/libc/include/sys/reent.h   | 118 +++---
 newlib/libc/reent/impure.c|   6 --
 newlib/libc/reent/reent.c |  20 -
 newlib/libc/stdio/fcloseall.c |   4 -
 newlib/libc/stdio/findfp.c|  53 +---
 newlib/libc/stdio/local.h |  17 
 winsup/cygwin/include/cygwin/config.h |   1 -
 10 files changed, 14 insertions(+), 228 deletions(-)

diff --git a/newlib/README b/newlib/README
index f00e66019..dd4686eeb 100644
--- a/newlib/README
+++ b/newlib/README
@@ -294,12 +294,6 @@ One feature can be enabled by specifying 
`--enable-FEATURE=yes' or
  Disable dynamic allocation of atexit entries.
  Most hosts and targets have it enabled in configure.host.
 
-`--enable-newlib-global-stdio-streams'
- Enable to move the stdio stream FILE objects out of struct _reent and make
- them global.  The stdio stream pointers of struct _reent are initialized
- to point to the global stdio FILE stream objects.
- Disabled by default.
-
 `--enable-newlib-reent-small'
  Enable small reentrant struct support.
  Disabled by default.
diff --git a/newlib/configure.ac b/newlib/configure.ac
index 57f830960..1951aab0c 100644
--- a/newlib/configure.ac
+++ b/newlib/configure.ac
@@ -174,13 +174,13 @@ AC_ARG_ENABLE(newlib-reent-binary-compat,
  fi], [newlib_reent_binary_compat=no])dnl
 
 dnl Support --enable-newlib-global-stdio-streams
+dnl This is no longer optional.  It is enabled in all Newlib configurations.
 AC_ARG_ENABLE(newlib-global-stdio-streams,
 [  --enable-newlib-global-stdio-streams   enable global stdio streams],
 [case "${enableval}" in
   yes) newlib_global_stdio_streams=yes;;
-  no)  newlib_global_stdio_streams=no ;;
   *)   AC_MSG_ERROR(bad value ${enableval} for newlib-global-stdio-streams 
option) ;;
- esac], [newlib_global_stdio_streams=])dnl
+ esac], [newlib_global_stdio_streams=yes])dnl
  
 dnl Support --disable-newlib-fvwrite-in-streamio
 AC_ARG_ENABLE(newlib-fvwrite-in-streamio,
@@ -435,12 +435,6 @@ if test "${newlib_reent_binary_compat}" = "yes"; then
   AC_DEFINE(_WANT_REENT_BACKWARD_BINARY_COMPAT, 1, [Define to enable backward 
binary compatibility for struct _reent.])
 fi
 
-if test "${newlib_global_stdio_streams}" = "yes"; then
-  AC_DEFINE(_WANT_REENT_GLOBAL_STDIO_STREAMS, 1,
-   [Define to move the stdio stream FILE objects out of struct _reent 
and make them global.
-The stdio stream pointers of struct _reent are initialized to 
point to the global stdio FILE stream objects.])
-fi
-
 _mb_len_max=1
 if test "${newlib_mb}" = "yes"; then
   AC_DEFINE(_MB_CAPABLE, 1, [Multibyte supported.])
diff --git a/newlib/libc/include/sys/config.h b/newlib/libc/include/sys/config.h
index c40bb51c2..4bce10de3 100644
--- a/newlib/libc/include/sys/config.h
+++ b/newlib/libc/include/sys/config.h
@@ -242,7 +242,6 @@
 #define __FILENAME_MAX__ 255
 #define _READ_WRITE_RETURN_TYPE _ssize_t
 #define __DYNAMIC_REENT__
-#define _REENT_GLOBAL_STDIO_STREAMS
 #endif
 
 #ifndef __EXPORT
@@ -280,12 +279,6 @@
 #endif
 #endif
 
-#ifdef _WANT_REENT_GLOBAL_STDIO_STREAMS
-#ifndef _REENT_GLOBAL_STDIO_STREAMS
-#define _REENT_GLOBAL_STDIO_STREAMS
-#endif
-#endif
-
 #ifdef 

Re: [PATCH 3/7] TFTPFS: Restore tftpDriver.c

2022-06-08 Thread Sebastian Huber

On 06/06/2022 17:34, Joel Sherrill wrote:
On Mon, Jun 6, 2022 at 9:02 AM Frank Kühndel 
> wrote:


Hello Joel,




*From: *"Joel Sherrill" mailto:j...@rtems.org>>
*To: *"Frank Kühndel" mailto:frank.kuehn...@embedded-brains.de>>
*Cc: *"rtems-de...@rtems.org "
mailto:devel@rtems.org>>
*Sent: *Saturday, June 4, 2022 1:05:25 AM
*Subject: *Re: [PATCH 3/7] TFTPFS: Restore tftpDriver.c

 > Is this really just a move/rename? Does it preserve the git blame
info?

This (PATCH 3/7) is really a file "copy/recreate" (git blame info
will *NOT* be preserved). The move/rename is (at the very beginning
of) PATCH 2/7. My understanding is, that the git blame info will be
"moved" by PATCH 2/7 from original file tftpDriver.c to the
"copied/moved" tftpfs.c file provided the person commiting the
patches does not apply the trick described in the link I send in the
cover letter of this patch set. If that trick is applied both files
tftpDriver.c and tftpfs.c will have an intact git blame info - at
least as long as nothing "surprising" like a git rebase happens.

My feeling is that more original code survived in tftpfs.c than in
tftpDriver.c. Therefore, in case the trick is not applied (i.e. only
one file ends up with an intact git blame info) it is preferable
that this be tftpfs.c.


OK. Work with Christian or Sebastian to make sure it gets committed 
correctly.


We don't use merge commits and never made any attempts to help git blame 
doing the right thing. I will just squash the commits together.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 0/1] Newlib01: Add tests for rand() and lrand48()

2022-06-08 Thread Matthew Joyce
From: Matt Joyce 

Hello,

This patch adds tests for rand() and lrand48(). It checks to ensure their state
is thread-specific, that they are properly initialized, and return the expected
sequence for default seed values.

Sincerely,

Matt

Matt Joyce (1):
  Newlib01: Add tests for rand() and lrand48()

 testsuites/libtests/newlib01/init.c   | 50 +++
 testsuites/libtests/newlib01/newlib01.doc |  3 ++
 2 files changed, 53 insertions(+)

-- 
2.31.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH 1/1] Newlib01: Add tests for rand() and lrand48()

2022-06-08 Thread Matthew Joyce
From: Matt Joyce 

Check that the state of rand() and lrand48() is thread-specific,
that they are properly initialized, and return the expected
sequence of pseudo-random numbers for default seed values.
---
 testsuites/libtests/newlib01/init.c   | 50 +++
 testsuites/libtests/newlib01/newlib01.doc |  3 ++
 2 files changed, 53 insertions(+)

diff --git a/testsuites/libtests/newlib01/init.c 
b/testsuites/libtests/newlib01/init.c
index 8975a72fad..0bb3c4628b 100644
--- a/testsuites/libtests/newlib01/init.c
+++ b/testsuites/libtests/newlib01/init.c
@@ -82,6 +82,50 @@ static void wait(void)
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 }
 
+/*
+ * Check that rand() is properly initialized and returns the expected sequence
+ * for default seed values. A call to rand() without any previous call to
+ * srand() generates the same sequence as when srand() is first called with a
+ * seed value of 1.
+ */
+static void test_rand(void)
+{
+  int rv;
+
+  rv = rand();
+  rtems_test_assert(rv == 1481765933);
+  rv = rand();
+  rtems_test_assert(rv == 1085377743);
+  rv = rand();
+  rtems_test_assert(rv == 1270216262);
+
+  srand(1);
+  rv = rand();
+  rtems_test_assert(rv == 1481765933);
+  rv = rand();
+  rtems_test_assert(rv == 1085377743);
+  rv = rand();
+  rtems_test_assert(rv == 1270216262);
+}
+
+/*
+ * Check that lrand48() is properly initialized and returns the expected
+ * sequence for default seed values. A call to lrand48() without any previous
+ * call to srand48() uses default constant initializer values set in the _seed
+ * member of struct _rand48.
+ */
+static void test_lrand48(void)
+{
+  long rv;
+
+  rv = lrand48();
+  rtems_test_assert(rv == 851401618);
+  rv = lrand48();
+  rtems_test_assert(rv == 1804928587);
+  rv = lrand48();
+  rtems_test_assert(rv == 758783491);
+}
+
 static void stdio_file_worker(rtems_task_argument arg)
 {
   test_context *ctx = _instance;
@@ -90,6 +134,9 @@ static void stdio_file_worker(rtems_task_argument arg)
   char buf[1] = { 'x' };
   size_t n;
 
+  test_rand();
+  test_lrand48();
+
   rtems_test_assert(reent->__cleanup == NULL);
 
   output = stdout = fopen(_file_path[0], "r+");
@@ -454,6 +501,9 @@ static void Init(rtems_task_argument arg)
   int rv;
 
   TEST_BEGIN();
+  test_rand();
+  test_lrand48();
+
   ctx->main_task_id = rtems_task_self();
 
   /* Fill dynamic file pool in Newlib */
diff --git a/testsuites/libtests/newlib01/newlib01.doc 
b/testsuites/libtests/newlib01/newlib01.doc
index fbda12aa98..dc16584418 100644
--- a/testsuites/libtests/newlib01/newlib01.doc
+++ b/testsuites/libtests/newlib01/newlib01.doc
@@ -19,3 +19,6 @@ concepts:
   - Check that exit procedures provide proper resource cleanup. Ensure that
 a file opened from a worker task--but that is not assigned to a stdio
 stream--is not closed during thread termination.
+  - Check that the state of random number generators is thread-specific, they
+are properly initialized, and return the expected sequence for default
+seed values.
-- 
2.31.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


AW: AW: AW: [PATCH] kern_tc.c: Update pps_event() for uniprocessor configurations

2022-06-08 Thread Gabriel.Moyano
>  I don't know why there is this "if" in the code. I will ask on a FreeBSD 
>  mailing list.
> 
> >>> I think it is for the case that th_generation has changed in between
> >>> saving the th and th_counter. If this happens pps->capgen is set to
> >>> 0 and later pps_event() returns earlier. Since for uniprocessor
> >>> th_generation equal to 0 is not used, I guess we can removed this if
> >>> for those configurations
> >> I asked on a FreeBSD mailing list:
> >>
> >> https://lists.freebsd.org/archives/freebsd-hackers/2022-June/001165.h
> >> tml
> >>
> > Thanks for asking.
> > I'll prepare and send a new patch removing the "if" for uniprocessor 
> > configurations just in case.
> 
> Please wait with a new patch for a response from FreeBSD.
> 
What is your suggestion here? Should we check the generation only once? Or 
should we leave the code as is and just remove the "if" in pps_capture() for 
uniprocessor configurations since th_generation equal to zero is not used?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[gcc] Enable TLS support for RTEMS in libstdc++

2022-06-08 Thread Sebastian Huber
libstdc++-v3/ChangeLog:

* crossconfig.m4 (*-rtems*): Enable TLS support for all RTEMS targets
except mips.
---
 libstdc++-v3/crossconfig.m4 | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index ae5283b7ad3..732f6818074 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -249,6 +249,13 @@ case "${host}" in
 GLIBCXX_CHECK_LINKER_FEATURES
 GLIBCXX_CHECK_MATH_SUPPORT
 GLIBCXX_CHECK_STDLIB_SUPPORT
+case "$target" in
+  mips*-rtems*)
+;;
+  *)
+AC_DEFINE(HAVE_TLS)
+;;
+esac
 ;;
   *-tpf)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'
-- 
2.35.3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel