Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[Chris Johns]

On 11/9/20 12:40 am, Joel Sherrill wrote:
> How is the user/system integrator supposed to figure out the size of the TLS? 
> It
> is not known until the application is linked and thus varies based on the 
> total
> set of code linked. 

Yes the user links the application and inspects the executable with 
rtems-exeinfo:

$ rtems-exeinfo -T riscv-rtems6/c/griscv/testsuites/sptests/sptls01.exe
exe: riscv-rtems6/c/griscv/testsuites/sptests/sptls01.exe

Compilation:
 Producers: 2
  |  GNU AS 2.35.50: 5 objects
  |  GNU C17 10.2.1 20200904 (RTEMS 6, RSB
31f936a7b74d60bda609a9960c6e1a705ba54974, Newlib a0d7982): 241 objects
 Common flags: 2
  | -march=rv32imafd -mabi=ilp32d

TLS size  : 1
data size : 1
 bss size : 0
alignment : 1
data addr : 0x400106b8

This is equivalent to how we manage stacks. For stacks you need to run the code
with an oversized stack, check the usage under all test conditions and then
derate by increasing the size by a % amount. TLS can be more accurate because
you link, have a look and then adjust your size then link again.

> As far as I can tell, this makes this type of task creation unsuitable for use
> in libraries where the end system is unknown.

Yes it is unsuitable and this is the problem with an API call, once we introduce
it we have no control over now it will be used.

I should also point out I will be less sympathetic to early adopters of this
call if we need to change things to make it more robust.

> It is at least fragile in tightly controlled applications and subject to 
> someone
> guessing a number larger than required which wastes memory and goes against 
> the
> intent of the statically allocated thread resources.

Sebastian and I discussed a disable for the call that needs to be enabled via
confdefs.h for the call to work. The idea is to catch any hidden usage.
Sebastian did not like this. Considering this some more I wonder if the TCB
should have a flag set to say the allocator was "static". This could be reported
by the `task` command and may be even via an API call. Users could then inspect
and check their system.

> If there is a practical and portable way to know this number, it needs to be
> explained quite well in the documentation and always used in any tests or 
> examples.

Or an error is reported if the call sees a problem with the resource allocation.

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

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[Sebastian Huber]

On 11/09/2020 09:00, Chris Johns wrote:


Considering this some more I wonder if the TCB
should have a flag set to say the allocator was "static". This could be reported
by the `task` command and may be even via an API call. Users could then inspect
and check their system.


We don't need a flag for this. We can just use:

the_thread->Start.stack_free == _Stack_Free

Adding this information to the task command could be helpful if we find 
a way to display it without needing to much space on the line.


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

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[Chris Johns]

On 11/9/20 5:07 pm, Sebastian Huber wrote:
> On 11/09/2020 09:00, Chris Johns wrote:
> 
>> Considering this some more I wonder if the TCB
>> should have a flag set to say the allocator was "static". This could be 
>> reported
>> by the `task` command and may be even via an API call. Users could then 
>> inspect
>> and check their system.
> 
> We don't need a flag for this. We can just use:
> 
> the_thread->Start.stack_free == _Stack_Free

Nice.

> Adding this information to the task command could be helpful if we find a way 
> to
> display it without needing to much space on the line.

They are making wider screens these days ... ;)

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

Re: New Build System Status

[Sebastian Huber]

Hello,

On 16/07/2020 17:16, Sebastian Huber wrote:

Hello,

I sent the documentation of the new build system some days ago and at 
least Gedare Bloom reviewed it.


https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf

https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf

I rebased the build system branch to the current master and squashed 
all commits:


https://git.rtems.org/sebh/rtems.git/log/?h=build-2

I started the development nearly one year ago and it was basically 
production ready in November last year. In the mean time Hesham 
Almatary added basic support for clang to it. Doorstop is no longer 
used. This simplified the YAML files a bit since no requirements 
related attributes are present in the build item files. The item links 
are now an ordered list. This simplified the build dependencies. The 
item paths are now also shorter since there is no longer a duplication 
of the directory path in the file name.


Each build item has a license and a copyright statement list. I didn't 
add copyright statements for the BSP option descriptions. If someone 
thinks there is a statement missing or the licensing conditions are 
not acceptable, we can add/change it later.


I built all BSPs with all tests enabled today using the latest RTEMS 5 
tool chain which is based on GCC 10. I had to disable the fenv test 
since the ARM support is currently broken.


The build system is ready to be merged from my point of view.


are there any remaining issues which prevent the new build system from 
being integrated? At the moment I just sit idle and wait. If there are 
technical issues, I can fix them only if I know them.


I have a BSP using the new build system for the STM32H7 chips with 
Ethernet and USB host support waiting for integration since April this year.


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

Re: New Build System Status

[Chris Johns]

On 11/9/20 5:14 pm, Sebastian Huber wrote:
> are there any remaining issues which prevent the new build system from being
> integrated? At the moment I just sit idle and wait. If there are technical
> issues, I can fix them only if I know them.

I have none.

> I have a BSP using the new build system for the STM32H7 chips with Ethernet 
> and
> USB host support waiting for integration since April this year.

I have the C++ threads with attributes patch I posted last year waiting to be
merged...

https://lists.rtems.org/pipermail/devel/2019-December/056436.html

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

Re: New coding style for new files?

[Sebastian Huber]

On 10/09/2020 17:32, Joel Sherrill wrote:




On Thu, Sep 10, 2020 at 10:24 AM Gedare Bloom > wrote:


On Mon, Sep 7, 2020 at 12:06 AM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>> wrote:
>
> Hello,
>
> I think we waste too much time to address coding style issues on
newly
> contributed code, for example GSoC. I don't know a source code
> formatting tool which supports the RTEMS coding style and I
think it is
> not worth the time to write and maintain such a tool
specifically for
> RTEMS. Why don't we simply allow an alternative coding style
which has a
> good code formatter for new source files? I don't propose to
reformat
> the existing files.
>
> I would simply pick up one of the standard styles supported by
> clang-format and declare it as an acceptable coding style for RTEMS.


I am not willing to blanket accept another project's coding style.

I am willing to accept a configuration for a tool that is close to our 
style and

make compromises on specific points.


We had a student to figure this out for clang-format some time ago:

https://lists.rtems.org/pipermail/devel/2019-February/024912.html

We could also have a look at uncrustify:

https://github.com/uncrustify/uncrustify

It seems to be still actively maintained on Github.



I also think when doing this we should consider things that we do that
we have since learned safety standards don't like such as single statement
if's without braces. I think we should have braces now.
I think uncrustify had options to do this. I am not sure if clang-format 
can do this.


This is best viewed as an opportunity to improve but comes with changes
since I don't think any of us wants to add a few more configuration 
options

to any formatter. Although if we get close, I can see adding those as open
projects if someone is interested.
Good, I think we should have a look at uncrustify. The RTEMS coding 
style is too exotic for clang-format.

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

x86 c++ exception handling

[Heinz Junkes]

Here is a mail I received from a colleague.

It concerns thereby an "old" problem which seemed already solved?

FYI. I can run the unit tests, but I'm seeing a couple of hangs.
The first I'm looking at is epicsTimeTest which seems to be
related to c++ exception handling.  I recall that there were
problems with x86 exception handling, but I also recall hearing
that this was fixed.

...
> * Starting EPICS application *
> 1..212
> ok  1 - epicsTime_gmtime() for EPICS epoch
> ok  2 - nanosecond overflow throws
... hangs ...

Attaching debugger shows:

> Program received signal SIGINT, Interrupt.
> libat_fetch_add_4 (mptr=0x757730, opval=4294967295, smodel=5) at 
> ../../../../gcc-7.5.0/libatomic/fop_n.c:44
> 44  ../../../../gcc-7.5.0/libatomic/fop_n.c: No such file or directory.
> (gdb) bt
> #0  libat_fetch_add_4 (mptr=0x757730, opval=4294967295, smodel=5) at 
> ../../../../gcc-7.5.0/libatomic/fop_n.c:44
> #1  0x003b07fc in __gnu_cxx::__exchange_and_add (__val=-1, __mem=0x757730)
>at 
> /home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:49
> #2  __gnu_cxx::__exchange_and_add_dispatch (__val=-1, __mem=0x757730)
>at 
> /home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:82
> #3  __gnu_cxx::__eh_atomic_dec (__count=0x757730) at 
> ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_atomics.h:72
> #4  __gxx_exception_cleanup (code=_URC_FOREIGN_EXCEPTION_CAUGHT, exc=0x757770)
>at ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_throw.cc:46
> #5  0x003ad9cb in _Unwind_DeleteException (exc=0x757770) at 
> ../../../../gcc-7.5.0/libgcc/unwind.inc:271
> #6  0x003af8d0 in __cxxabiv1::__cxa_end_catch () at 
> ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_catch.cc:125
> #7  0x001012fd in epicsTimeTest () at ../epicsTimeTest.cpp:116
> (gdb)

Viele Grüße
Heinz



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: x86 c++ exception handling

[Sebastian Huber]

On 11/09/2020 10:48, Heinz Junkes wrote:


Here is a mail I received from a colleague.

It concerns thereby an "old" problem which seemed already solved?

FYI. I can run the unit tests, but I'm seeing a couple of hangs.
The first I'm looking at is epicsTimeTest which seems to be
related to c++ exception handling.  I recall that there were
problems with x86 exception handling, but I also recall hearing
that this was fixed.

...

* Starting EPICS application *
1..212
ok  1 - epicsTime_gmtime() for EPICS epoch
ok  2 - nanosecond overflow throws

... hangs ...

Attaching debugger shows:


Program received signal SIGINT, Interrupt.
libat_fetch_add_4 (mptr=0x757730, opval=4294967295, smodel=5) at 
../../../../gcc-7.5.0/libatomic/fop_n.c:44
44  ../../../../gcc-7.5.0/libatomic/fop_n.c: No such file or directory.
(gdb) bt
#0  libat_fetch_add_4 (mptr=0x757730, opval=4294967295, smodel=5) at 
../../../../gcc-7.5.0/libatomic/fop_n.c:44
#1  0x003b07fc in __gnu_cxx::__exchange_and_add (__val=-1, __mem=0x757730)
at 
/home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:49
#2  __gnu_cxx::__exchange_and_add_dispatch (__val=-1, __mem=0x757730)
at 
/home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:82
#3  __gnu_cxx::__eh_atomic_dec (__count=0x757730) at 
../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_atomics.h:72
#4  __gxx_exception_cleanup (code=_URC_FOREIGN_EXCEPTION_CAUGHT, exc=0x757770)
at ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_throw.cc:46
#5  0x003ad9cb in _Unwind_DeleteException (exc=0x757770) at 
../../../../gcc-7.5.0/libgcc/unwind.inc:271
#6  0x003af8d0 in __cxxabiv1::__cxa_end_catch () at 
../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_catch.cc:125
#7  0x001012fd in epicsTimeTest () at ../epicsTimeTest.cpp:116
(gdb)


There is also an associated ticket:

http://devel.rtems.org/ticket/2830

I think the i386 BSPs need to be cleaned up to use an instruction set 
which fits current the x86 hardware. I mean hardware which is still in 
use and not some stuff from the 1990s.


For example if I compile this test

#include 

int add(atomic_int *i, int v)
{
    return atomic_fetch_add(i, v);
}

on my Linux machine, I get:

gcc -O2 -S -o - test.c -m32
    .file   "test.c"
    .text
    .p2align 4,,15
    .globl  add
    .type   add, @function
add:
.LFB0:
    .cfi_startproc
    movl    4(%esp), %edx
    movl    8(%esp), %eax
    lock xaddl  %eax, (%edx)
    ret
    .cfi_endproc
.LFE0:
    .size   add, .-add
    .ident  "GCC: (SUSE Linux) 7.5.0"
    .section    .note.GNU-stack,"",@progbits

There is no call to libatomic.



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

Re: x86 c++ exception handling

[Karel Gardas]

On 9/11/20 11:12 AM, Sebastian Huber wrote:
> On 11/09/2020 10:48, Heinz Junkes wrote:
> 
>> Here is a mail I received from a colleague.
>>
>> It concerns thereby an "old" problem which seemed already solved?
>>
>> FYI. I can run the unit tests, but I'm seeing a couple of hangs.
>> The first I'm looking at is epicsTimeTest which seems to be
>> related to c++ exception handling.  I recall that there were
>> problems with x86 exception handling, but I also recall hearing
>> that this was fixed.
>>
>> ...
>>> * Starting EPICS application *
>>> 1..212
>>> ok  1 - epicsTime_gmtime() for EPICS epoch
>>> ok  2 - nanosecond overflow throws
>> ... hangs ...
>>
>> Attaching debugger shows:
>>
>>> Program received signal SIGINT, Interrupt.
>>> libat_fetch_add_4 (mptr=0x757730, opval=4294967295, smodel=5) at
>>> ../../../../gcc-7.5.0/libatomic/fop_n.c:44
>>> 44  ../../../../gcc-7.5.0/libatomic/fop_n.c: No such file or
>>> directory.
>>> (gdb) bt
>>> #0  libat_fetch_add_4 (mptr=0x757730, opval=4294967295, smodel=5) at
>>> ../../../../gcc-7.5.0/libatomic/fop_n.c:44
>>> #1  0x003b07fc in __gnu_cxx::__exchange_and_add (__val=-1,
>>> __mem=0x757730)
>>>     at
>>> /home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:49
>>>
>>> #2  __gnu_cxx::__exchange_and_add_dispatch (__val=-1, __mem=0x757730)
>>>     at
>>> /home/mdavidsaver/source/rtems/rtems-source-builder-5.1/rtems/build/i386-rtems5-gcc-7.5.0-newlib-7947581-x86_64-linux-gnu-1/build/i386-rtems5/mpentiumpro/libstdc++-v3/include/ext/atomicity.h:82
>>>
>>> #3  __gnu_cxx::__eh_atomic_dec (__count=0x757730) at
>>> ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_atomics.h:72
>>> #4  __gxx_exception_cleanup (code=_URC_FOREIGN_EXCEPTION_CAUGHT,
>>> exc=0x757770)
>>>     at ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_throw.cc:46
>>> #5  0x003ad9cb in _Unwind_DeleteException (exc=0x757770) at
>>> ../../../../gcc-7.5.0/libgcc/unwind.inc:271
>>> #6  0x003af8d0 in __cxxabiv1::__cxa_end_catch () at
>>> ../../../../../gcc-7.5.0/libstdc++-v3/libsupc++/eh_catch.cc:125
>>> #7  0x001012fd in epicsTimeTest () at ../epicsTimeTest.cpp:116
>>> (gdb)
> 
> There is also an associated ticket:
> 
> http://devel.rtems.org/ticket/2830
> 
> I think the i386 BSPs need to be cleaned up to use an instruction set
> which fits current the x86 hardware. I mean hardware which is still in
> use and not some stuff from the 1990s.
> 

If I'm not mistaken, then this is simply fixed by using other BSP's
variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs
and gcc's lib provides necessary synchronization functions then...

Please correct me if I'm wrong,

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

Re: x86 c++ exception handling

[Sebastian Huber]

On 11/09/2020 11:21, Karel Gardas wrote:


There is also an associated ticket:

http://devel.rtems.org/ticket/2830

I think the i386 BSPs need to be cleaned up to use an instruction set
which fits current the x86 hardware. I mean hardware which is still in
use and not some stuff from the 1990s.


If I'm not mistaken, then this is simply fixed by using other BSP's
variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs
and gcc's lib provides necessary synchronization functions then...
The question is if there are RTEMS users in this universe which have x64 
hardware in use which understands only the pc486/pc586/pc686 instruction 
sets. This is stuff from the 1990s.

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

Re: x86 c++ exception handling

[Karel Gardas]

On 9/11/20 11:40 AM, Sebastian Huber wrote:

>> If I'm not mistaken, then this is simply fixed by using other BSP's
>> variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs
>> and gcc's lib provides necessary synchronization functions then...
> The question is if there are RTEMS users in this universe which have x64
> hardware in use which understands only the pc486/pc586/pc686 instruction
> sets. This is stuff from the 1990s.

OK! So first uarch from 2000s is NetBurts and later core. Would you like
to stop on that? Honestly I'm a bit confused since if you are talking
about obsoleting '90s then we're in amd64 territory and then the
question is if to keep 32bit BSP or go straight to 64bit. Unfortunately
amd64 BSP provides just clock and console IIRC and and in comparison
with that pc386 supports a lot more features (VESA fb, libbsd)...

Or do you propose to just add more BSP variants to pc386 to support
optimization/isns generation for more modern CPUs and deprecate older
variants?

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

Re: x86 c++ exception handling

[Sebastian Huber]

On 11/09/2020 12:08, Karel Gardas wrote:


On 9/11/20 11:40 AM, Sebastian Huber wrote:


If I'm not mistaken, then this is simply fixed by using other BSP's
variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs
and gcc's lib provides necessary synchronization functions then...

The question is if there are RTEMS users in this universe which have x64
hardware in use which understands only the pc486/pc586/pc686 instruction
sets. This is stuff from the 1990s.

OK! So first uarch from 2000s is NetBurts and later core. Would you like
to stop on that? Honestly I'm a bit confused since if you are talking
about obsoleting '90s then we're in amd64 territory and then the
question is if to keep 32bit BSP or go straight to 64bit. Unfortunately
amd64 BSP provides just clock and console IIRC and and in comparison
with that pc386 supports a lot more features (VESA fb, libbsd)...

Or do you propose to just add more BSP variants to pc386 to support
optimization/isns generation for more modern CPUs and deprecate older
variants?
I don't know. I think we should somehow figure out which x86 hardware is 
in use by RTEMS users.

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

Re: New Build System Status

[Christian Mauderer]

On 11/09/2020 09:19, Chris Johns wrote:
> On 11/9/20 5:14 pm, Sebastian Huber wrote:
>> are there any remaining issues which prevent the new build system from being
>> integrated? At the moment I just sit idle and wait. If there are technical
>> issues, I can fix them only if I know them.
> 
> I have none.

Hello Sebastian,

I think there has been one patch for libbsd that was necessary when
building the BSP with the new build system. You created it somewhen
during summer and I used it in a test build for a GSoC project:

https://gitlab.com/c-mauderer/rtems-libbsd/-/commit/c9474c0b228d91dff098d617234842d56af3c4d7

Beneath that I had no build system related problems for the BBB BSP.

Best regards

Christian

> 
>> I have a BSP using the new build system for the STM32H7 chips with Ethernet 
>> and
>> USB host support waiting for integration since April this year.
> 
> I have the C++ threads with attributes patch I posted last year waiting to be
> merged...
> 
> https://lists.rtems.org/pipermail/devel/2019-December/056436.html
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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

pc386 BSP/master branch build failure with smp enabled.

[Karel Gardas]

Hello,

I've built 6/rtems-i386 tools using master branch of rtems-source-builder.

$ i386-rtems6-gcc -v
Using built-in specs.
COLLECT_GCC=i386-rtems6-gcc
COLLECT_LTO_WRAPPER=/export/home/karel/sfw/rtems/6-head-2020-09-11/libexec/gcc/i386-rtems6/10.2.1/lto-wrapper
Target: i386-rtems6
Configured with: ../gnu-mirror-gcc-75f5776/configure
--prefix=/export/home/karel/sfw/rtems/6-head-2020-09-11
--bindir=/export/home/karel/sfw/rtems/6-head-2020-09-11/bin
--exec_prefix=/export/home/karel/sfw/rtems/6-head-2020-09-11
--includedir=/export/home/karel/sfw/rtems/6-head-2020-09-11/include
--libdir=/export/home/karel/sfw/rtems/6-head-2020-09-11/lib
--libexecdir=/export/home/karel/sfw/rtems/6-head-2020-09-11/libexec
--mandir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share/man
--infodir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share/info
--datadir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=i386-rtems6
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose
--with-newlib --disable-nls --without-included-gettext
--disable-win32-registry --enable-version-specific-runtime-libs
--disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--enable-threads --disable-plugin --enable-libgomp --enable-languages=c,c++
Thread model: rtems
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20200904 (RTEMS 6, RSB
a81a237f3e2318d88a16b31aadb82333498e06fd, Newlib a0d7982) (GCC)


I'm using those tools to build pc686 BSP with SMP enabled. The BSP is
configured with:

$ ../rtems-head/configure --prefix=$HOME/sfw/rtems/6-head-2020-09-11/
--target=i386-rtems6 --enable-maintainer-mode --enable-rtemsbsp=pc686
--enable-posix --enable-smp

The build fails with:

make[4]: Entering directory
'/export/home/karel/git/rtems/obj-rtems6/i386-rtems6/c/pc686/cpukit'
depbase=`echo score/cpu/i386/cpu_asm.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
i386-rtems6-gcc --pipe -DHAVE_CONFIG_H   -I.
-I/export/home/karel/git/rtems/obj-rtems6/i386-rtems6/c/pc686/include
-I/export/home/karel/git/rtems/rtems-head/cpukit/include
-I/export/home/karel/git/rtems/rtems-head/cpukit/score/cpu/i386/include
-I/export/home/karel/git/rtems/rtems-head/cpukit/libnetworking  -DASM
-mtune=pentiumpro -march=pentium -O2 -g -ffunction-sections
-fdata-sections -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
-mtune=pentiumpro -march=pentium -O2 -g -ffunction-sections
-fdata-sections -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT
score/cpu/i386/cpu_asm.o -MD -MP -MF $depbase.Tpo -c -o
score/cpu/i386/cpu_asm.o
../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S &&\
mv -f $depbase.Tpo $depbase.Po
../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S:
Assembler messages:
../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S:54: Error:
`%edx' not allowed with `movb'
../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S:78: 
Warning:
no instruction mnemonic suffix given and no register operands; using
default for `bts'
../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S:93: Error:
`%ecx' not allowed with `movb'
../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S:118:
Error: `%edx' not allowed with `movb'
Makefile:11553: recipe for target 'score/cpu/i386/cpu_asm.o' failed
make[4]: *** [score/cpu/i386/cpu_asm.o] Error 1
make[4]: Leaving directory
'/export/home/karel/git/rtems/obj-rtems6/i386-rtems6/c/pc686/cpukit'
Makefile:1272: recipe for target 'cpukit' failed
make[3]: *** [cpukit] Error 2

it seems the problematic code was added by the patch:

commit 8937f12f1884f08c8a53fc339d60b1021846882a
Author: Jan Sommer 
Date:   Sun May 31 16:22:54 2020 +0200

bsp/pc386: Update context switch and restore

Uses similar flow in cpu_asm.S for i386 as for arm.


Shall I add a ticket for this or am I doing anything wrong/unexpected here?

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

Re: x86 c++ exception handling

[Joel Sherrill]

On Fri, Sep 11, 2020 at 5:12 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 11/09/2020 12:08, Karel Gardas wrote:
>
> > On 9/11/20 11:40 AM, Sebastian Huber wrote:
> >
> >>> If I'm not mistaken, then this is simply fixed by using other BSP's
> >>> variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs
> >>> and gcc's lib provides necessary synchronization functions then...
> >> The question is if there are RTEMS users in this universe which have x64
> >> hardware in use which understands only the pc486/pc586/pc686 instruction
> >> sets. This is stuff from the 1990s.
> > OK! So first uarch from 2000s is NetBurts and later core. Would you like
> > to stop on that? Honestly I'm a bit confused since if you are talking
> > about obsoleting '90s then we're in amd64 territory and then the
> > question is if to keep 32bit BSP or go straight to 64bit. Unfortunately
> > amd64 BSP provides just clock and console IIRC and and in comparison
> > with that pc386 supports a lot more features (VESA fb, libbsd)...
> >
> > Or do you propose to just add more BSP variants to pc386 to support
> > optimization/isns generation for more modern CPUs and deprecate older
> > variants?
> I don't know. I think we should somehow figure out which x86 hardware is
> in use by RTEMS users.
>

Agreed. But  I don't see removing the 32-bit port/BSP.

it is simple to remove the lower end configurations and
ensure the lowest one includes the appropriate instructions.
The cleanup side-effects I see so far are:

+ remove GCC multilibs < certain level
+ Clean up i386.h in port for removed variants which will at least
   result in removal of port code for bit scan on i386 (i486 had
   an efficient instruction)
+ remove BSP code for CPUs < 586 w/o TBR.
+ documenting the rationale clearly in the Users Guide

Removing the BSP config variants below a certain level is trivial
in code but like deleting sis likely will result in questions and fixing
odd documentation references for a while.

FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced
in 1989. The Pentium was 1993. Remember It's All About the Pentium!
Pentium II was 1997 and first with SMP but maybe not setting the baseline
we want.

--joel

___
> 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: x86 c++ exception handling

[Karel Gardas]

On 9/11/20 3:13 PM, Joel Sherrill wrote:
> FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced
> in 1989. The Pentium was 1993. Remember It's All About the Pentium!
> Pentium II was 1997 and first with SMP but maybe not setting the baseline
> we want.

What about to support in master what man can currently purchase? If so,
then based on my limited research it looks like the cpu family
(orderable) goes back to 2016/2015 which support architecture of more or
less NetBurst uarch isn set (both intel and amd).

One exception found is Vertex86 cpus which still sells and boards are
available and which are compatible only with i586/p5 from as you noted
1993...

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

Re: x86 c++ exception handling

[Karel Gardas]

On 9/11/20 4:06 PM, Karel Gardas wrote:
> One exception found is Vertex86 cpus which still sells and boards are

Typo correction: Vortex86: https://en.wikipedia.org/wiki/Vortex86

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

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[Joel Sherrill]

This thread has wandered a lot but I just wanted to say
I am OK with the direction this is going.  I think we have
made this about as safe and easy to use as possible.

Did we decide if there had to be an explicit configure
option to even use this API? Chris and I discussed this
as an idea to force a user to make a very conscious
decision to allow it.

There does need to be documentation on the allocation
strategies, when to use, limitations, and particularly the
use of rtems-exeinfo to get the TLS size. This is one case
for sure where an RTEMS Tool needs explicit mention in
both the API and configure option sections.

I have had flashbacks to how often we got used to get questions
about why adding a sleep(1) in the middle of hello world locked
up. Then we added an option to say "does not need clock
driver" and the user questions stopped.  I would rather be a
bit aggressive on setup and avoid this for tasks with statically
allocated resources.

--joel

On Fri, Sep 11, 2020 at 2:08 AM Chris Johns  wrote:

> On 11/9/20 5:07 pm, Sebastian Huber wrote:
> > On 11/09/2020 09:00, Chris Johns wrote:
> >
> >> Considering this some more I wonder if the TCB
> >> should have a flag set to say the allocator was "static". This could be
> reported
> >> by the `task` command and may be even via an API call. Users could then
> inspect
> >> and check their system.
> >
> > We don't need a flag for this. We can just use:
> >
> > the_thread->Start.stack_free == _Stack_Free
>
> Nice.
>
> > Adding this information to the task command could be helpful if we find
> a way to
> > display it without needing to much space on the line.
>
> They are making wider screens these days ... ;)
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: x86 c++ exception handling

[Joel Sherrill]

On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas 
wrote:

> On 9/11/20 3:13 PM, Joel Sherrill wrote:
> > FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced
> > in 1989. The Pentium was 1993. Remember It's All About the Pentium!
> > Pentium II was 1997 and first with SMP but maybe not setting the baseline
> > we want.
>
> What about to support in master what man can currently purchase? If so,
> then based on my limited research it looks like the cpu family
> (orderable) goes back to 2016/2015 which support architecture of more or
> less NetBurst uarch isn set (both intel and amd).
>
> One exception found is Vertex86 cpus which still sells and boards are
> available and which are compatible only with i586/p5 from as you noted
> 1993...
>

Karel: Typo correction: Vortex86: https://en.wikipedia.org/wiki/Vortex86

If I am reading that right, we may be ok dumping i386 and i486 completely
and assuming around a Pentium II as default. Rather than a blanket drop
32-bit support which kills a LOT of usable functionality, I would rather
find
a new floor for the CPU model.

My recollection from SMP testing i386 on qemu was that the lowest CPU
model on Qemu that worked was core2duo which pc586-sse matches for
GCC arguments.

CPU_CFLAGS = -mtune=pentium -march=pentium -msse2

Is that lower than the broken code in GCC? What's the lowest multilib
where the atomics are right? Assuming that it isn't just a bug below that
level.

I would like to pick a floor based on some reasonable rationale
like GCC needs feature X for atomics which appears in CPU model Y.

I don't think Qemu provides a rationale for a floor. Availability of SoCs
for embedded systems seems like a short list and the wikipedia page
doesn't encourage me that they are viable options as most look dead
or barely breathing (parrot is dead):

https://en.wikipedia.org/wiki/List_of_x86_manufacturers

That leaves us with what's the lowest multilib in GCC where atomics
work (or can be fixed, assuming this is a bug).

--joel


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

[PATCH v4 1/5] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[Sebastian Huber]

Add this application configuration option.  This configuration option can be
used to reserve space for the dynamic linking of modules with thread-local
storage objects.

Update #4074.
---
 cpukit/doxygen/appl-config.h| 29 +++
 cpukit/include/rtems/confdefs/threads.h |  7 +++
 cpukit/include/rtems/score/interr.h |  3 +-
 cpukit/include/rtems/score/thread.h | 10 
 cpukit/sapi/src/interrtext.c|  5 +-
 cpukit/score/src/tlsallocsize.c | 16 --
 testsuites/sptests/Makefile.am  |  9 
 testsuites/sptests/configure.ac |  1 +
 testsuites/sptests/spfatal33/init.c | 55 +
 testsuites/sptests/spfatal33/spfatal33.doc  | 11 +
 testsuites/sptests/spfatal33/spfatal33.scn  | 16 ++
 testsuites/sptests/spinternalerror02/init.c |  4 +-
 12 files changed, 158 insertions(+), 8 deletions(-)
 create mode 100644 testsuites/sptests/spfatal33/init.c
 create mode 100644 testsuites/sptests/spfatal33/spfatal33.doc
 create mode 100644 testsuites/sptests/spfatal33/spfatal33.scn

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index cd4664f7c8..25dbaead7c 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -801,6 +801,35 @@
  */
 #define CONFIGURE_MAXIMUM_TASKS
 
+/**
+ * @brief This configuration option is an integer define.
+ *
+ * If the value of this configuration option is greater than zero, then it
+ * defines the maximum thread-local storage size, otherwise the thread-local
+ * storage size is defined by the linker depending on the thread-local storage
+ * objects used by the application in the statically-linked executable.
+ *
+ * @par Default Value
+ * The default value is 0.
+ *
+ * @par Value Constraints
+ * The value of this configuration option shall be greater than or equal to 0
+ * and less than or equal to https://en.cppreference.com/w/c/types/limits";>SIZE_MAX.
+ *
+ * @par Notes
+ * @parblock
+ * This configuration option can be used to reserve space for the dynamic
+ * linking of modules with thread-local storage objects.
+ *
+ * If the thread-local storage size defined by the thread-local storage objects
+ * used by the application in the statically-linked executable is greater than
+ * a non-zero value of this configuration option, then a fatal error will occur
+ * during system initialization.
+ * @endparblock
+ */
+#define CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE
+
 /**
  * @brief This configuration option is an integer define.
  *
diff --git a/cpukit/include/rtems/confdefs/threads.h 
b/cpukit/include/rtems/confdefs/threads.h
index 33b8c5cee2..9e34696e61 100644
--- a/cpukit/include/rtems/confdefs/threads.h
+++ b/cpukit/include/rtems/confdefs/threads.h
@@ -84,6 +84,10 @@
   #define CONFIGURE_MAXIMUM_THREAD_NAME_SIZE THREAD_DEFAULT_MAXIMUM_NAME_SIZE
 #endif
 
+#ifndef CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE
+  #define CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE 0
+#endif
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -125,6 +129,9 @@ typedef union {
 
 const size_t _Thread_Maximum_name_size = CONFIGURE_MAXIMUM_THREAD_NAME_SIZE;
 
+const size_t _Thread_Maximum_TLS_size =
+  CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE;
+
 struct Thread_Configured_control {
   Thread_Control Control;
   #if CONFIGURE_MAXIMUM_USER_EXTENSIONS > 0
diff --git a/cpukit/include/rtems/score/interr.h 
b/cpukit/include/rtems/score/interr.h
index 2f449deedb..1371e55653 100644
--- a/cpukit/include/rtems/score/interr.h
+++ b/cpukit/include/rtems/score/interr.h
@@ -203,7 +203,8 @@ typedef enum {
   INTERNAL_ERROR_LIBIO_STDERR_FD_OPEN_FAILED = 37,
   INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT = 38,
   INTERNAL_ERROR_ARC4RANDOM_GETENTROPY_FAIL = 39,
-  INTERNAL_ERROR_NO_MEMORY_FOR_PER_CPU_DATA = 40
+  INTERNAL_ERROR_NO_MEMORY_FOR_PER_CPU_DATA = 40,
+  INTERNAL_ERROR_TOO_LARGE_TLS_SIZE = 41
 } Internal_errors_Core_list;
 
 typedef CPU_Uint32ptr Internal_errors_t;
diff --git a/cpukit/include/rtems/score/thread.h 
b/cpukit/include/rtems/score/thread.h
index 1daf6143f9..1388744548 100644
--- a/cpukit/include/rtems/score/thread.h
+++ b/cpukit/include/rtems/score/thread.h
@@ -953,6 +953,16 @@ extern const size_t _Thread_Initial_thread_count;
  */
 extern const size_t _Thread_Maximum_name_size;
 
+/**
+ * @brief If this constant is greater than zero, then it defines the maximum
+ * thread-local storage size, otherwise the thread-local storage size is 
defined
+ * by the linker depending on the thread-local storage objects used by the
+ * application in the statically-linked executable.
+ *
+ * This value is provided via .
+ */
+extern const size_t _Thread_Maximum_TLS_size;
+
 /**
  * @brief The configured thread control block.
  *
diff --git a/cpukit/sapi/src/interrtext.c b/cpukit/sapi/src/interrtext.c
index 2aff34487a..3d49135c44 100644
--- a/cpukit/sapi/src/interrtext.c
+++ b/cpukit/sapi/src/interrtext.c
@@ -7,7 +7,7 @@
  */
 
 /*
- * Copyright (c) 2012

[PATCH v4 3/5] doxygen: Move top-level group definitions

[Sebastian Huber]

Update #3959.
---
 cpukit/doxygen.h  | 18 -
 cpukit/doxygen/top-level-groups.h | 44 +++
 2 files changed, 44 insertions(+), 18 deletions(-)
 create mode 100644 cpukit/doxygen/top-level-groups.h

diff --git a/cpukit/doxygen.h b/cpukit/doxygen.h
index ba75c80349..c159b2082d 100644
--- a/cpukit/doxygen.h
+++ b/cpukit/doxygen.h
@@ -1,9 +1,3 @@
-/**
- * @defgroup RTEMSInternal Internal
- *
- * @brief RTEMS Implementation.
- */
-
 /**
  * @defgroup RTEMSInternalClassic Classic
  * 
@@ -12,12 +6,6 @@
  * @brief Classic
  */
 
-/**
- * @defgroup RTEMSAPI API
- *
- * @brief API
- */
-
 /**
  * @defgroup RTEMSAPIIO IO
  *
@@ -42,12 +30,6 @@
  * @brief Tracing
  */
 
-/**
- * @defgroup RTEMSDeviceDrivers Device Drivers
- *
- * @brief Device Drivers
- */
-
 /**
  * @defgroup RTEMSLegacyBenchmarkDrivers Legacy Benchmark Drivers
  *
diff --git a/cpukit/doxygen/top-level-groups.h 
b/cpukit/doxygen/top-level-groups.h
new file mode 100644
index 00..a177e8a715
--- /dev/null
+++ b/cpukit/doxygen/top-level-groups.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2019, 2020 embedded brains GmbH 
(http://www.embedded-brains.de)
+ *
+ * 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.
+ */
+
+/**
+ * @defgroup RTEMSAPI API
+ *
+ * @brief API
+ */
+
+/**
+ * @defgroup RTEMSDeviceDrivers Device Drivers
+ *
+ * @brief Device Drivers
+ */
+
+/**
+ * @defgroup RTEMSInternal Internal
+ *
+ * @brief RTEMS Implementation.
+ */
-- 
2.26.2

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

[PATCH v4 4/5] validation: Add general purpose test suite

[Sebastian Huber]

Add a general purpose test suite for validation tests.

This is the first test suite generated from a specification item in the
rtems-central repository.

Update #3959.
---
 Doxyfile|   2 +-
 cpukit/doxygen/top-level-groups.h   |   6 +
 testsuites/validation/ts-validation-0.c | 217 
 3 files changed, 224 insertions(+), 1 deletion(-)
 create mode 100644 testsuites/validation/ts-validation-0.c

diff --git a/Doxyfile b/Doxyfile
index c794938191..ffb87fe89d 100644
--- a/Doxyfile
+++ b/Doxyfile
@@ -812,7 +812,7 @@ WARN_LOGFILE   =
 # spaces. See also FILE_PATTERNS and EXTENSION_MAPPING
 # Note: If this tag is empty the current directory is searched.
 
-INPUT  = bsps cpukit
+INPUT  = bsps cpukit testsuites/validation
 
 # This tag can be used to specify the character encoding of the source files
 # that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
diff --git a/cpukit/doxygen/top-level-groups.h 
b/cpukit/doxygen/top-level-groups.h
index a177e8a715..c1a91a3482 100644
--- a/cpukit/doxygen/top-level-groups.h
+++ b/cpukit/doxygen/top-level-groups.h
@@ -42,3 +42,9 @@
  *
  * @brief RTEMS Implementation.
  */
+
+/**
+ * @defgroup RTEMSTestSuites Test Suites
+ *
+ * @brief Collection of Test Suites
+ */
diff --git a/testsuites/validation/ts-validation-0.c 
b/testsuites/validation/ts-validation-0.c
new file mode 100644
index 00..3f61b70a3f
--- /dev/null
+++ b/testsuites/validation/ts-validation-0.c
@@ -0,0 +1,217 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestSuiteTestsuitesValidation0
+ */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * 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.
+ */
+
+/*
+ * This file was automatically generated.  Do not edit it manually.
+ * Please have a look at
+ *
+ * https://docs.rtems.org/branches/master/eng/req/howto.html
+ *
+ * for information how to maintain and re-generate this file.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+
+#include 
+
+/**
+ * @defgroup RTEMSTestSuiteTestsuitesValidation0 spec:/testsuites/validation-0
+ *
+ * @ingroup RTEMSTestSuites
+ *
+ * @brief This general purpose validation test suite provides enough resources
+ *   to run basic tests for all specified managers and functions.
+ *
+ * In SMP configurations, up to three scheduler instances using the SMP EDF
+ * scheduler are provided using up to four processors.
+ *
+ * @{
+ */
+
+#include 
+
+const char rtems_test_name[] = "Validation0";
+
+static char buffer[ 512 ];
+
+static const T_action actions[] = {
+  T_report_hash_sha256,
+  T_check_task_context,
+  T_check_rtems_barriers,
+  T_check_rtems_extensions,
+  T_check_rtems_message_queues,
+  T_check_rtems_partitions,
+  T_check_rtems_periods,
+  T_check_rtems_semaphores,
+  T_check_rtems_tasks,
+  T_check_rtems_timers
+};
+
+static const T_config test_config = {
+  .name = rtems_test_name,
+  .buf = buffer,
+  .buf_size = sizeof( buffer ),
+  .putchar = rtems_put_char,
+  .verbosity = T_VERBOSE,
+  .now = T_now_clock,
+  .action_count = T_ARRAY_SIZE( actions ),
+  .actions = actions
+};
+
+static void runner_task( rtems_task_argument arg )
+{
+  int exit_code;
+
+  (void) arg;
+
+  rtems_test_begin( rtems_test_name, TEST_STATE );
+  T_register();
+  exit_code = T_main( &test_config );
+
+  if ( exit_code == 0 ) {
+rtems_test_end( rtems_test_name );
+  }
+
+  rtems_fatal( RTEMS_FATAL_SOURCE_EXIT, (uint32_t) exit_code );
+}
+
+#define MAX_TLS_SIZE 64
+#define ATTRIBUTES RTEMS_FLOATING_POINT
+
+RTEMS_TASK_STORAGE_ALIGNMENT static char runner_t

[PATCH v4 2/5] rtems: Add rtems_task_create_from_config()

[Sebastian Huber]

In contrast to rtems_task_create() this function creates a task with a
user-provided task storage area.  The new create function uses a
configuration structure instead of individual parameters.

Add RTEMS_TASK_STORAGE_ALIGNMENT to define the recommended alignment of
a task storage area.

Add RTEMS_TASK_STORAGE_SIZE() to calculate the recommended size of a
task storage area based on the task attributes and the size dedicated to
the task stack and thread-local storage.  This macro may allow future
extensions without breaking the API.

Add application configuration option CONFIGURE_TASKS_CREATED_FROM_CONFIG to
adjust RTEMS Workspace size estimate.

Update #3959.
---
 cpukit/Makefile.am  |   1 +
 cpukit/doxygen/appl-config.h|  23 ++
 cpukit/include/rtems/confdefs/threads.h |   8 +
 cpukit/include/rtems/confdefs/wkspace.h |   4 +-
 cpukit/include/rtems/rtems/tasks.h  | 163 +
 cpukit/include/rtems/rtems/tasksimpl.h  |  11 +
 cpukit/rtems/src/taskcreate.c   | 282 +-
 cpukit/rtems/src/taskcreatefromconfig.c | 300 
 testsuites/sptests/sp01/init.c  |  24 +-
 testsuites/sptests/sp01/sp01.doc|   1 +
 testsuites/sptests/sp01/system.h|   3 +-
 11 files changed, 584 insertions(+), 236 deletions(-)
 create mode 100644 cpukit/rtems/src/taskcreatefromconfig.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index e5009e53c9..caa6a9efe6 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -787,6 +787,7 @@ librtemscpu_a_SOURCES += rtems/src/statustoerrno.c
 librtemscpu_a_SOURCES += rtems/src/systemeventreceive.c
 librtemscpu_a_SOURCES += rtems/src/systemeventsend.c
 librtemscpu_a_SOURCES += rtems/src/taskcreate.c
+librtemscpu_a_SOURCES += rtems/src/taskcreatefromconfig.c
 librtemscpu_a_SOURCES += rtems/src/taskdelete.c
 librtemscpu_a_SOURCES += rtems/src/taskexit.c
 librtemscpu_a_SOURCES += rtems/src/taskgetaffinity.c
diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index 25dbaead7c..6e9e11c9f7 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -893,6 +893,29 @@
  */
 #define CONFIGURE_MAXIMUM_USER_EXTENSIONS
 
+/**
+ * @brief This configuration option is an integer define.
+ *
+ * The value of this configuration option defines the count of Classic API
+ * Tasks which are created by rtems_task_create_from_config().
+ *
+ * @par Default Value
+ * The default value is 0.
+ *
+ * @par Value Constraints
+ * The value of this configuration option shall be greater than or equal to 0
+ * and less than or equal to #CONFIGURE_MAXIMUM_TASKS.
+ *
+ * @par Notes
+ * By default, the calculation for the required memory in the RTEMS Workspace
+ * for tasks assumes that all Classic API Tasks are created by
+ * rtems_task_create().  This configuration option can be used to reduce the
+ * required memory for the system-provided task storage areas since tasks
+ * created by rtems_task_create_from_config() use a user-provided task storage
+ * area.
+ */
+#define CONFIGURE_TASKS_CREATED_FROM_CONFIG
+
 /** @} */
 
 /**
diff --git a/cpukit/include/rtems/confdefs/threads.h 
b/cpukit/include/rtems/confdefs/threads.h
index 9e34696e61..9c86ff21ca 100644
--- a/cpukit/include/rtems/confdefs/threads.h
+++ b/cpukit/include/rtems/confdefs/threads.h
@@ -60,6 +60,14 @@
 
 #define _CONFIGURE_TASKS ( CONFIGURE_MAXIMUM_TASKS + _CONFIGURE_LIBBLOCK_TASKS 
)
 
+#ifndef CONFIGURE_TASKS_CREATED_FROM_CONFIG
+  #define CONFIGURE_TASKS_CREATED_FROM_CONFIG 0
+#endif
+
+#if CONFIGURE_TASKS_CREATED_FROM_CONFIG > CONFIGURE_MAXIMUM_TASKS
+  #error "CONFIGURE_TASKS_CREATED_FROM_CONFIG shall be less than or equal to 
CONFIGURE_MAXIMUM_TASKS"
+#endif
+
 #ifndef CONFIGURE_MAXIMUM_POSIX_THREADS
   #define CONFIGURE_MAXIMUM_POSIX_THREADS 0
 #endif
diff --git a/cpukit/include/rtems/confdefs/wkspace.h 
b/cpukit/include/rtems/confdefs/wkspace.h
index de476dbf82..215cdcb141 100644
--- a/cpukit/include/rtems/confdefs/wkspace.h
+++ b/cpukit/include/rtems/confdefs/wkspace.h
@@ -100,7 +100,9 @@
 + _CONFIGURE_POSIX_INIT_THREAD_STACK_EXTRA \
 + _CONFIGURE_LIBBLOCK_TASKS_STACK_EXTRA \
 + CONFIGURE_EXTRA_TASK_STACKS \
-+ rtems_resource_maximum_per_allocation( _CONFIGURE_TASKS ) \
++ rtems_resource_maximum_per_allocation( \
+_CONFIGURE_TASKS - CONFIGURE_TASKS_CREATED_FROM_CONFIG \
+  ) \
   * _Configure_From_stackspace( CONFIGURE_MINIMUM_TASK_STACK_SIZE ) \
 + rtems_resource_maximum_per_allocation( CONFIGURE_MAXIMUM_POSIX_THREADS ) 
\
   * _Configure_From_stackspace( CONFIGURE_MINIMUM_POSIX_THREAD_STACK_SIZE 
) \
diff --git a/cpukit/include/rtems/rtems/tasks.h 
b/cpukit/include/rtems/rtems/tasks.h
index 12c323e60e..092528b4de 100644
--- a/cpukit/include/rtems/rtems/tasks.h
+++ b/cpukit/include/rtems/rtems/tasks.h
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -164,6 +165,168 @@ rtems_status_code rtems_task_create(

[PATCH v4 0/5] rtems: Add rtems_task_create_from_config()

[Sebastian Huber]

v2:

Rename function from rtems_task_build() to
rtems_task_create_from_config().  Add RTEMS_TASK_STORAGE_ALIGNMENT and
RTEMS_TASK_STORAGE_SIZE().  Improve documentation.

v3:

Add CONFIGURE_TASKS_CREATED_FROM_CONFIG.  Fix RTEMS_TASK_STORAGE_SIZE() if
CPU_ALL_TASKS_ARE_FP == TRUE.

v4:

Add CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE to control the maximum size
reserved for thread-local storage.

Add maximum_thread_local_storage_size member to rtems_task_config to check that
the thread-local storage size in the task configuration is sufficient for the
actual thread-local storage size of the application.

Add a general purpose test suite for basic validation tests.  Add a validation
test case to check the rtems_task_create_from_config() error cases.  The code
is generated from specification items:

https://git.rtems.org/rtems-central/tree/spec/testsuites/validation-0.yml

https://git.rtems.org/rtems-central/tree/spec/req/rtems/tasks/create-from-config-errors.yml

The build system part of the new tests is not included in the patch set.  I
don't want to add a new test suite for the old build system.

Sebastian Huber (5):
  CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE
  rtems: Add rtems_task_create_from_config()
  doxygen: Move top-level group definitions
  validation: Add general purpose test suite
  validation: rtems_task_create_from_config() errors

 Doxyfile  |2 +-
 cpukit/Makefile.am|1 +
 cpukit/doxygen.h  |   18 -
 cpukit/doxygen/appl-config.h  |   52 +
 cpukit/doxygen/top-level-groups.h |   50 +
 cpukit/include/rtems/confdefs/threads.h   |   15 +
 cpukit/include/rtems/confdefs/wkspace.h   |4 +-
 cpukit/include/rtems/rtems/tasks.h|  163 ++
 cpukit/include/rtems/rtems/tasksimpl.h|   11 +
 cpukit/include/rtems/score/interr.h   |3 +-
 cpukit/include/rtems/score/thread.h   |   10 +
 cpukit/rtems/src/taskcreate.c |  282 +-
 cpukit/rtems/src/taskcreatefromconfig.c   |  300 +++
 cpukit/sapi/src/interrtext.c  |5 +-
 cpukit/score/src/tlsallocsize.c   |   16 +-
 testsuites/sptests/Makefile.am|9 +
 testsuites/sptests/configure.ac   |1 +
 testsuites/sptests/sp01/init.c|   24 +-
 testsuites/sptests/sp01/sp01.doc  |1 +
 testsuites/sptests/sp01/system.h  |3 +-
 testsuites/sptests/spfatal33/init.c   |   55 +
 testsuites/sptests/spfatal33/spfatal33.doc|   11 +
 testsuites/sptests/spfatal33/spfatal33.scn|   16 +
 testsuites/sptests/spinternalerror02/init.c   |4 +-
 .../tc-tasks-create-from-config-errors.c  | 2369 +
 testsuites/validation/ts-validation-0.c   |  217 ++
 26 files changed, 3379 insertions(+), 263 deletions(-)
 create mode 100644 cpukit/doxygen/top-level-groups.h
 create mode 100644 cpukit/rtems/src/taskcreatefromconfig.c
 create mode 100644 testsuites/sptests/spfatal33/init.c
 create mode 100644 testsuites/sptests/spfatal33/spfatal33.doc
 create mode 100644 testsuites/sptests/spfatal33/spfatal33.scn
 create mode 100644 testsuites/validation/tc-tasks-create-from-config-errors.c
 create mode 100644 testsuites/validation/ts-validation-0.c

-- 
2.26.2

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

[PATCH v4 5/5] validation: rtems_task_create_from_config() errors

[Sebastian Huber]

This is the first test case generated from a specification item in the
rtems-central repository.

Update #3959.
---
 .../tc-tasks-create-from-config-errors.c  | 2369 +
 1 file changed, 2369 insertions(+)
 create mode 100644 testsuites/validation/tc-tasks-create-from-config-errors.c

diff --git a/testsuites/validation/tc-tasks-create-from-config-errors.c 
b/testsuites/validation/tc-tasks-create-from-config-errors.c
new file mode 100644
index 00..1b10621a61
--- /dev/null
+++ b/testsuites/validation/tc-tasks-create-from-config-errors.c
@@ -0,0 +1,2369 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestCaseReqRtemsTasksCreateFromConfigErrors
+ */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * 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.
+ */
+
+/*
+ * This file was automatically generated.  Do not edit it manually.
+ * Please have a look at
+ *
+ * https://docs.rtems.org/branches/master/eng/req/howto.html
+ *
+ * for information how to maintain and re-generate this file.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/**
+ * @defgroup RTEMSTestCaseReqRtemsTasksCreateFromConfigErrors \
+ *   spec:/req/rtems/tasks/create-from-config-errors
+ *
+ * @ingroup RTEMSTestSuiteTestsuitesValidation0
+ *
+ * @{
+ */
+
+typedef enum {
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Id_Id,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Id_Null,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Id_NA
+} ReqRtemsTasksCreateFromConfigErrors_Pre_Id;
+
+typedef enum {
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Name_Valid,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Name_Inv,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Name_NA
+} ReqRtemsTasksCreateFromConfigErrors_Pre_Name;
+
+typedef enum {
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Prio_Valid,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Prio_Zero,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Prio_Inv,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Prio_NA
+} ReqRtemsTasksCreateFromConfigErrors_Pre_Prio;
+
+typedef enum {
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Tasks_Avail,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Tasks_None,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Tasks_NA
+} ReqRtemsTasksCreateFromConfigErrors_Pre_Tasks;
+
+typedef enum {
+  ReqRtemsTasksCreateFromConfigErrors_Pre_TLS_Enough,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_TLS_Small,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_TLS_NA
+} ReqRtemsTasksCreateFromConfigErrors_Pre_TLS;
+
+typedef enum {
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Stack_Enough,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Stack_Small,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Stack_NA
+} ReqRtemsTasksCreateFromConfigErrors_Pre_Stack;
+
+typedef enum {
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Ext_Ok,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Ext_Err,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Ext_NA
+} ReqRtemsTasksCreateFromConfigErrors_Pre_Ext;
+
+typedef enum {
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Preempt_Yes,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Preempt_No,
+  ReqRtemsTasksCreateFromConfigErrors_Pre_Preempt_NA
+} ReqRtemsTasksCreateFromConfigErrors_Pre_Preempt;
+
+typedef enum {
+  ReqRtemsTasksCreateFromConfigErrors_Post_Status_Ok,
+  ReqRtemsTasksCreateFromConfigErrors_Post_Status_InvAddress,
+  ReqRtemsTasksCreateFromConfigErrors_Post_Status_InvName,
+  ReqRtemsTasksCreateFromConfigErrors_Post_Status_InvPrio,
+  ReqRtemsTasksCreateFromConfigErrors_Post_Status_InvSize,
+  ReqRtemsTasksCreateFromConfigErrors_Post_Status_TooMany,
+  ReqRtemsTasksCreateFromConfigErrors_Post_Status_Unsatisfied,
+  ReqRtemsTasksC

Re: New Build System Status

[Gedare Bloom]

I have nothing pending. I think we should switch early next week, sort
out any bugs during the week?

On Fri, Sep 11, 2020 at 4:52 AM Christian Mauderer
 wrote:
>
> On 11/09/2020 09:19, Chris Johns wrote:
> > On 11/9/20 5:14 pm, Sebastian Huber wrote:
> >> are there any remaining issues which prevent the new build system from 
> >> being
> >> integrated? At the moment I just sit idle and wait. If there are technical
> >> issues, I can fix them only if I know them.
> >
> > I have none.
>
> Hello Sebastian,
>
> I think there has been one patch for libbsd that was necessary when
> building the BSP with the new build system. You created it somewhen
> during summer and I used it in a test build for a GSoC project:
>
> https://gitlab.com/c-mauderer/rtems-libbsd/-/commit/c9474c0b228d91dff098d617234842d56af3c4d7
>
> Beneath that I had no build system related problems for the BBB BSP.
>
> Best regards
>
> Christian
>
> >
> >> I have a BSP using the new build system for the STM32H7 chips with 
> >> Ethernet and
> >> USB host support waiting for integration since April this year.
> >
> > I have the C++ threads with attributes patch I posted last year waiting to 
> > be
> > merged...
> >
> > https://lists.rtems.org/pipermail/devel/2019-December/056436.html
> >
> > Chris
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> 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: New coding style for new files?

[Gedare Bloom]

On Fri, Sep 11, 2020 at 1:41 AM Sebastian Huber
 wrote:
>
> On 10/09/2020 17:32, Joel Sherrill wrote:
>
> >
> >
> > On Thu, Sep 10, 2020 at 10:24 AM Gedare Bloom  > > wrote:
> >
> > On Mon, Sep 7, 2020 at 12:06 AM Sebastian Huber
> >  > > wrote:
> > >
> > > Hello,
> > >
> > > I think we waste too much time to address coding style issues on
> > newly
> > > contributed code, for example GSoC. I don't know a source code
> > > formatting tool which supports the RTEMS coding style and I
> > think it is
> > > not worth the time to write and maintain such a tool
> > specifically for
> > > RTEMS. Why don't we simply allow an alternative coding style
> > which has a
> > > good code formatter for new source files? I don't propose to
> > reformat
> > > the existing files.
> > >
> > > I would simply pick up one of the standard styles supported by
> > > clang-format and declare it as an acceptable coding style for RTEMS.
> >
> >
> > I am not willing to blanket accept another project's coding style.
> >
> > I am willing to accept a configuration for a tool that is close to our
> > style and
> > make compromises on specific points.
>
> We had a student to figure this out for clang-format some time ago:
>
> https://lists.rtems.org/pipermail/devel/2019-February/024912.html
>
> We could also have a look at uncrustify:
>
> https://github.com/uncrustify/uncrustify
>
> It seems to be still actively maintained on Github.
>
> >
> > I also think when doing this we should consider things that we do that
> > we have since learned safety standards don't like such as single statement
> > if's without braces. I think we should have braces now.
> I think uncrustify had options to do this. I am not sure if clang-format
> can do this.
> >
> > This is best viewed as an opportunity to improve but comes with changes
> > since I don't think any of us wants to add a few more configuration
> > options
> > to any formatter. Although if we get close, I can see adding those as open
> > projects if someone is interested.
> Good, I think we should have a look at uncrustify. The RTEMS coding
> style is too exotic for clang-format.

Let's start with uncrustify. The github looks solid with
cross-platform compatibility claims (*nix, Windows, OSX).

I know that there was an RTEMS style script generated by Sebastian
some time ago. We had it on the wiki forever, but now it is a broken
link in the docs
https://devel.rtems.org/attachment/wiki/Developer/Coding/Conventions/rtems.uncrustify

from https://docs.rtems.org/branches/master/eng/coding-conventions.html#tools

So we'll need to revive that first, and iterate.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: pc386 BSP/master branch build failure with smp enabled.

[Gedare Bloom]

Looks to be coming through

cpukit/score/cpu/i386/include/rtems/asm.h:157   movb
imps_apic_cpu_map(\REG),\REG/* CPU ID in REG */

The assembler is right to complain. movb has to target one of the
1-byte mnemonics, so this should be %al for the LSB of %eax. One needs
to check through this logic carefully, but I think the right thing to
do here is:
movzbl imps_apic_cpu_map(\REG),\REG

That should do the trick. Can you test it locally?

On Fri, Sep 11, 2020 at 6:54 AM Karel Gardas  wrote:
>
>
> Hello,
>
> I've built 6/rtems-i386 tools using master branch of rtems-source-builder.
>
> $ i386-rtems6-gcc -v
> Using built-in specs.
> COLLECT_GCC=i386-rtems6-gcc
> COLLECT_LTO_WRAPPER=/export/home/karel/sfw/rtems/6-head-2020-09-11/libexec/gcc/i386-rtems6/10.2.1/lto-wrapper
> Target: i386-rtems6
> Configured with: ../gnu-mirror-gcc-75f5776/configure
> --prefix=/export/home/karel/sfw/rtems/6-head-2020-09-11
> --bindir=/export/home/karel/sfw/rtems/6-head-2020-09-11/bin
> --exec_prefix=/export/home/karel/sfw/rtems/6-head-2020-09-11
> --includedir=/export/home/karel/sfw/rtems/6-head-2020-09-11/include
> --libdir=/export/home/karel/sfw/rtems/6-head-2020-09-11/lib
> --libexecdir=/export/home/karel/sfw/rtems/6-head-2020-09-11/libexec
> --mandir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share/man
> --infodir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share/info
> --datadir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=i386-rtems6
> --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose
> --with-newlib --disable-nls --without-included-gettext
> --disable-win32-registry --enable-version-specific-runtime-libs
> --disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv
> --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
> --enable-threads --disable-plugin --enable-libgomp --enable-languages=c,c++
> Thread model: rtems
> Supported LTO compression algorithms: zlib
> gcc version 10.2.1 20200904 (RTEMS 6, RSB
> a81a237f3e2318d88a16b31aadb82333498e06fd, Newlib a0d7982) (GCC)
>
>
> I'm using those tools to build pc686 BSP with SMP enabled. The BSP is
> configured with:
>
> $ ../rtems-head/configure --prefix=$HOME/sfw/rtems/6-head-2020-09-11/
> --target=i386-rtems6 --enable-maintainer-mode --enable-rtemsbsp=pc686
> --enable-posix --enable-smp
>
> The build fails with:
>
> make[4]: Entering directory
> '/export/home/karel/git/rtems/obj-rtems6/i386-rtems6/c/pc686/cpukit'
> depbase=`echo score/cpu/i386/cpu_asm.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> i386-rtems6-gcc --pipe -DHAVE_CONFIG_H   -I.
> -I/export/home/karel/git/rtems/obj-rtems6/i386-rtems6/c/pc686/include
> -I/export/home/karel/git/rtems/rtems-head/cpukit/include
> -I/export/home/karel/git/rtems/rtems-head/cpukit/score/cpu/i386/include
> -I/export/home/karel/git/rtems/rtems-head/cpukit/libnetworking  -DASM
> -mtune=pentiumpro -march=pentium -O2 -g -ffunction-sections
> -fdata-sections -Wall -Wmissing-prototypes
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
> -mtune=pentiumpro -march=pentium -O2 -g -ffunction-sections
> -fdata-sections -Wall -Wmissing-prototypes
> -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT
> score/cpu/i386/cpu_asm.o -MD -MP -MF $depbase.Tpo -c -o
> score/cpu/i386/cpu_asm.o
> ../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S &&\
> mv -f $depbase.Tpo $depbase.Po
> ../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S:
> Assembler messages:
> ../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S:54: 
> Error:
> `%edx' not allowed with `movb'
> ../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S:78: 
> Warning:
> no instruction mnemonic suffix given and no register operands; using
> default for `bts'
> ../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S:93: 
> Error:
> `%ecx' not allowed with `movb'
> ../../../../../rtems-head/c/src/../../cpukit/score/cpu/i386/cpu_asm.S:118:
> Error: `%edx' not allowed with `movb'
> Makefile:11553: recipe for target 'score/cpu/i386/cpu_asm.o' failed
> make[4]: *** [score/cpu/i386/cpu_asm.o] Error 1
> make[4]: Leaving directory
> '/export/home/karel/git/rtems/obj-rtems6/i386-rtems6/c/pc686/cpukit'
> Makefile:1272: recipe for target 'cpukit' failed
> make[3]: *** [cpukit] Error 2
>
> it seems the problematic code was added by the patch:
>
> commit 8937f12f1884f08c8a53fc339d60b1021846882a
> Author: Jan Sommer 
> Date:   Sun May 31 16:22:54 2020 +0200
>
> bsp/pc386

Re: New coding style for new files?

[Joel Sherrill]

On Fri, Sep 11, 2020 at 11:06 AM Gedare Bloom  wrote:

> On Fri, Sep 11, 2020 at 1:41 AM Sebastian Huber
>  wrote:
> >
> > On 10/09/2020 17:32, Joel Sherrill wrote:
> >
> > >
> > >
> > > On Thu, Sep 10, 2020 at 10:24 AM Gedare Bloom  > > > wrote:
> > >
> > > On Mon, Sep 7, 2020 at 12:06 AM Sebastian Huber
> > >  > > > wrote:
> > > >
> > > > Hello,
> > > >
> > > > I think we waste too much time to address coding style issues on
> > > newly
> > > > contributed code, for example GSoC. I don't know a source code
> > > > formatting tool which supports the RTEMS coding style and I
> > > think it is
> > > > not worth the time to write and maintain such a tool
> > > specifically for
> > > > RTEMS. Why don't we simply allow an alternative coding style
> > > which has a
> > > > good code formatter for new source files? I don't propose to
> > > reformat
> > > > the existing files.
> > > >
> > > > I would simply pick up one of the standard styles supported by
> > > > clang-format and declare it as an acceptable coding style for
> RTEMS.
> > >
> > >
> > > I am not willing to blanket accept another project's coding style.
> > >
> > > I am willing to accept a configuration for a tool that is close to our
> > > style and
> > > make compromises on specific points.
> >
> > We had a student to figure this out for clang-format some time ago:
> >
> > https://lists.rtems.org/pipermail/devel/2019-February/024912.html
> >
> > We could also have a look at uncrustify:
> >
> > https://github.com/uncrustify/uncrustify
> >
> > It seems to be still actively maintained on Github.
> >
> > >
> > > I also think when doing this we should consider things that we do that
> > > we have since learned safety standards don't like such as single
> statement
> > > if's without braces. I think we should have braces now.
> > I think uncrustify had options to do this. I am not sure if clang-format
> > can do this.
> > >
> > > This is best viewed as an opportunity to improve but comes with changes
> > > since I don't think any of us wants to add a few more configuration
> > > options
> > > to any formatter. Although if we get close, I can see adding those as
> open
> > > projects if someone is interested.
> > Good, I think we should have a look at uncrustify. The RTEMS coding
> > style is too exotic for clang-format.
>
> Let's start with uncrustify. The github looks solid with
> cross-platform compatibility claims (*nix, Windows, OSX).
>
> I know that there was an RTEMS style script generated by Sebastian
> some time ago. We had it on the wiki forever, but now it is a broken
> link in the docs
>
> https://devel.rtems.org/attachment/wiki/Developer/Coding/Conventions/rtems.uncrustify
>
> from
> https://docs.rtems.org/branches/master/eng/coding-conventions.html#tools
>
> So we'll need to revive that first, and iterate.
>

Amar has backups of the old wiki based on wikipedia and I think he can
access it easily.

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

Re: New coding style for new files?

[Joel Sherrill]

https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify

On Fri, Sep 11, 2020 at 11:46 AM Joel Sherrill  wrote:

>
>
> On Fri, Sep 11, 2020 at 11:06 AM Gedare Bloom  wrote:
>
>> On Fri, Sep 11, 2020 at 1:41 AM Sebastian Huber
>>  wrote:
>> >
>> > On 10/09/2020 17:32, Joel Sherrill wrote:
>> >
>> > >
>> > >
>> > > On Thu, Sep 10, 2020 at 10:24 AM Gedare Bloom > > > > wrote:
>> > >
>> > > On Mon, Sep 7, 2020 at 12:06 AM Sebastian Huber
>> > > > > > > wrote:
>> > > >
>> > > > Hello,
>> > > >
>> > > > I think we waste too much time to address coding style issues on
>> > > newly
>> > > > contributed code, for example GSoC. I don't know a source code
>> > > > formatting tool which supports the RTEMS coding style and I
>> > > think it is
>> > > > not worth the time to write and maintain such a tool
>> > > specifically for
>> > > > RTEMS. Why don't we simply allow an alternative coding style
>> > > which has a
>> > > > good code formatter for new source files? I don't propose to
>> > > reformat
>> > > > the existing files.
>> > > >
>> > > > I would simply pick up one of the standard styles supported by
>> > > > clang-format and declare it as an acceptable coding style for
>> RTEMS.
>> > >
>> > >
>> > > I am not willing to blanket accept another project's coding style.
>> > >
>> > > I am willing to accept a configuration for a tool that is close to our
>> > > style and
>> > > make compromises on specific points.
>> >
>> > We had a student to figure this out for clang-format some time ago:
>> >
>> > https://lists.rtems.org/pipermail/devel/2019-February/024912.html
>> >
>> > We could also have a look at uncrustify:
>> >
>> > https://github.com/uncrustify/uncrustify
>> >
>> > It seems to be still actively maintained on Github.
>> >
>> > >
>> > > I also think when doing this we should consider things that we do that
>> > > we have since learned safety standards don't like such as single
>> statement
>> > > if's without braces. I think we should have braces now.
>> > I think uncrustify had options to do this. I am not sure if clang-format
>> > can do this.
>> > >
>> > > This is best viewed as an opportunity to improve but comes with
>> changes
>> > > since I don't think any of us wants to add a few more configuration
>> > > options
>> > > to any formatter. Although if we get close, I can see adding those as
>> open
>> > > projects if someone is interested.
>> > Good, I think we should have a look at uncrustify. The RTEMS coding
>> > style is too exotic for clang-format.
>>
>> Let's start with uncrustify. The github looks solid with
>> cross-platform compatibility claims (*nix, Windows, OSX).
>>
>> I know that there was an RTEMS style script generated by Sebastian
>> some time ago. We had it on the wiki forever, but now it is a broken
>> link in the docs
>>
>> https://devel.rtems.org/attachment/wiki/Developer/Coding/Conventions/rtems.uncrustify
>>
>> from
>> https://docs.rtems.org/branches/master/eng/coding-conventions.html#tools
>>
>> So we'll need to revive that first, and iterate.
>>
>
> Amar has backups of the old wiki based on wikipedia and I think he can
> access it easily.
>
> --joel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: pc386 BSP/master branch build failure with smp enabled.

[Karel Gardas]

On 9/11/20 6:16 PM, Gedare Bloom wrote:
> Looks to be coming through
> 
> cpukit/score/cpu/i386/include/rtems/asm.h:157   movb
> imps_apic_cpu_map(\REG),\REG/* CPU ID in REG */
> 
> The assembler is right to complain. movb has to target one of the
> 1-byte mnemonics, so this should be %al for the LSB of %eax. One needs
> to check through this logic carefully, but I think the right thing to
> do here is:
> movzbl imps_apic_cpu_map(\REG),\REG
> 
> That should do the trick. Can you test it locally?

Sure! Builds fine and testsuite testing reveals:


on Ubuntu 18.04 LTS's Qemu 2.11.1:

Passed:625
Failed:  9
User Input:  6
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 5
Invalid: 7
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 655
Failures:
 dl06.exe
 psx12.exe
 psxfenv01.exe
 smpmulticast01.exe
 spfatal26.exe
 spfatal30.exe
 sptimecounter02.exe
 tm26.exe
 tmcontext01.exe
User Input:
 dl10.exe
 monitor.exe
 termios.exe
 top.exe
 capture.exe
 fileio.exe
Benchmark:
 linpack.exe
 whetstone.exe
 dhrystone.exe
Timeouts:
 dl05.exe
 ttest02.exe
 cdtest.exe
 cxx_iostream.exe
 smpopenmp01.exe
Invalid:
 smpfatal09.exe
 spfatal06.exe
 spfatal09.exe
 spfatal12.exe
 spinternalerror01.exe
 spstkalloc02.exe
 sptimecounter01.exe
Average test time: 0:00:00.535252
Testing time : 0:05:50.589935


on qemu 5.1.0:

Passed:626
Failed:  7
User Input:  6
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 6
Invalid: 7
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 655
Failures:
 dl06.exe
 psx12.exe
 psxfenv01.exe
 smpfatal03.exe
 smpmulticast01.exe
 spfatal30.exe
 tmcontext01.exe
User Input:
 dl10.exe
 monitor.exe
 termios.exe
 top.exe
 capture.exe
 fileio.exe
Benchmark:
 linpack.exe
 whetstone.exe
 dhrystone.exe
Timeouts:
 dl05.exe
 ttest02.exe
 cdtest.exe
 cxx_iostream.exe
 smpopenmp01.exe
 spfatal26.exe
Invalid:
 smpfatal09.exe
 spfatal06.exe
 spfatal09.exe
 spfatal12.exe
 spinternalerror01.exe
 spstkalloc02.exe
 sptimecounter01.exe
Average test time: 0:00:00.705858
Testing time : 0:07:42.336669


and finally on qemu 4.2.1:

Passed:627
Failed:  6
User Input:  6
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 6
Invalid: 7
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 655
Failures:
 dl06.exe
 psx12.exe
 psxfenv01.exe
 smpmulticast01.exe
 spfatal30.exe
 tmcontext01.exe
User Input:
 dl10.exe
 monitor.exe
 termios.exe
 top.exe
 capture.exe
 fileio.exe
Benchmark:
 whetstone.exe
 dhrystone.exe
 linpack.exe
Timeouts:
 dl05.exe
 ttest02.exe
 cdtest.exe
 cxx_iostream.exe
 smpopenmp01.exe
 spfatal26.exe
Invalid:
 smpfatal09.exe
 spfatal06.exe
 spfatal09.exe
 spfatal12.exe
 spinternalerror01.exe
 spstkalloc02.exe
 sptimecounter01.exe
Average test time: 0:00:00.705055
Testing time : 0:07:41.811329


> 
> On Fri, Sep 11, 2020 at 6:54 AM Karel Gardas  wrote:
>>
>>
>> Hello,
>>
>> I've built 6/rtems-i386 tools using master branch of rtems-source-builder.
>>
>> $ i386-rtems6-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=i386-rtems6-gcc
>> COLLECT_LTO_WRAPPER=/export/home/karel/sfw/rtems/6-head-2020-09-11/libexec/gcc/i386-rtems6/10.2.1/lto-wrapper
>> Target: i386-rtems6
>> Configured with: ../gnu-mirror-gcc-75f5776/configure
>> --prefix=/export/home/karel/sfw/rtems/6-head-2020-09-11
>> --bindir=/export/home/karel/sfw/rtems/6-head-2020-09-11/bin
>> --exec_prefix=/export/home/karel/sfw/rtems/6-head-2020-09-11
>> --includedir=/export/home/karel/sfw/rtems/6-head-2020-09-11/include
>> --libdir=/export/home/karel/sfw/rtems/6-head-2020-09-11/lib
>> --libexecdir=/export/home/karel/sfw/rtems/6-head-2020-09-11/libexec
>> --mandir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share/man
>> --infodir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share/info
>> --datadir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share
>> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=i386-rtems6
>> --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose
>> --with-newlib --disable-nls --without-included-gettext
>> --disable-win32-registry --enable-version-specific-runtime-libs
>> --disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv
>> --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
>> --enable-threads --disable-plugin --enable-libgomp --enable-languages=c,c++
>> Thread model: rtems
>> Supported LTO compres

Re: New Build System Status

[Sebastian Huber]

On 11/09/2020 17:46, Gedare Bloom wrote:


I have nothing pending. I think we should switch early next week, sort
out any bugs during the week?
This sounds good. I can do some final tests builds over the week end and 
then push it on Monday morning.

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

Re: New coding style for new files?

[Peter Dufault]

> On Sep 11, 2020, at 13:43 , Joel Sherrill  wrote:
> 
> https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify
> 

I've been using "uncrustify" for a long time. There are regular updates and 
quick responses for clearly reported issues.

The formatting specification is complicated, but that goes along with being so 
configurable.  There are formatting specification GUIs and helpers that I 
haven't used to assist with the generation of the formatting spec. See the 
bottom of the main "github" page for "uncrustify".

Joel, when you were working with me the source code reformatting script we were 
using used "uncrustify" as the main reformatting engine.

I can not help with this much.  However, if I had time to do it, I think I'd do 
it this way:

- Choose files that the RTEMS community RTEMS agrees are perfect examples of 
RTEMS coding as reference sources.  There should be a few and some should be 
large.
- The "uncrustify" source includes sample configurations in its source code 
"/etc" directory.  Use a subset of the sample configurations to reformat the 
RTEMS reference sources.  For example, reformat to match FreeBSD, Linux kernel, 
K&R, etc coding styles and store them as test input files.
- Run "uncrustify" with a proposed RTEMS configuration file on the hacked 
reference files and then "diff" them with the original.

Ideally you would wind up with an RTEMS configuration with no diffs regardless 
of how you reformatted the input.

I know this would use the same tool that is being tested to create the input 
test files, but I think in this case it's OK due to how invasively "uncrustify" 
can be configured to reformat the code.  For example, it can probably strip "{" 
"}" on single lines in a conditional.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.



signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New coding style for new files?

[Joel Sherrill]

On Fri, Sep 11, 2020 at 1:11 PM Peter Dufault  wrote:

>
>
> > On Sep 11, 2020, at 13:43 , Joel Sherrill  wrote:
> >
> > https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify
> >
>
> I've been using "uncrustify" for a long time. There are regular updates
> and quick responses for clearly reported issues.
>
> The formatting specification is complicated, but that goes along with
> being so configurable.  There are formatting specification GUIs and helpers
> that I haven't used to assist with the generation of the formatting spec.
> See the bottom of the main "github" page for "uncrustify".
>
> Joel, when you were working with me the source code reformatting script we
> were using used "uncrustify" as the main reformatting engine.
>

I didn't know since it was hidden. :)

>
> I can not help with this much.  However, if I had time to do it, I think
> I'd do it this way:
>
> - Choose files that the RTEMS community RTEMS agrees are perfect examples
> of RTEMS coding as reference sources.  There should be a few and some
> should be large.
> - The "uncrustify" source includes sample configurations in its source
> code "/etc" directory.  Use a subset of the sample configurations to
> reformat the RTEMS reference sources.  For example, reformat to match
> FreeBSD, Linux kernel, K&R, etc coding styles and store them as test input
> files.
> - Run "uncrustify" with a proposed RTEMS configuration file on the hacked
> reference files and then "diff" them with the original.
>
> Ideally you would wind up with an RTEMS configuration with no diffs
> regardless of how you reformatted the input.
>

This is a decent plan. There are at least 12 files over 400 lines in the
cpukit (score, rtems, sapi, and libcsupport) that I would consider
potential candidates for this.

This matches my idea of minimizing the delta between defined current style
and what the tool supports. Then we can decide to bend to the tool or push
for changes to the tool.


> I know this would use the same tool that is being tested to create the
> input test files, but I think in this case it's OK due to how invasively
> "uncrustify" can be configured to reformat the code.  For example, it can
> probably strip "{" "}" on single lines in a conditional.
>

I like dense code and will admit it. I don't like styles that spread braces
onto separate lines so you end up with this:

if ()
{
...
}
else
{
}

But I have come to appreciate that single like if's with no braces can be
viewed as issues in safety and security coding standards so I am willing to
give that up and a tool will help fix those with low effort if we get a
good match on the other rules.

FWIW I have also come to believe that anything other than a single logical
test in a logical expression should be eliminated or at least avoided. I
just came off a project where doing that gave us very high Statement
Coverage and produced no cases where MC/DC coverage analysis had to be
done. A tool can't rework compound logical expressions into a series of
simple ones, but we may want to consider a style that discourages any
logical expression that would require MC/DC analysis. This appears to be a
decent discussion of the topics:

https://people.eecs.ku.edu/~hossein/Teaching/Fa09/814/Lectures/structural-testing-mcdc-tut.pdf

Thanks Peter. This does appear to be the approach to narrowing down the
settings and getting to where we can trust them.

--joel


>
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
>
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New Build System Status

[Gedare Bloom]

On Fri, Sep 11, 2020 at 12:03 PM Sebastian Huber
 wrote:
>
> On 11/09/2020 17:46, Gedare Bloom wrote:
>
> > I have nothing pending. I think we should switch early next week, sort
> > out any bugs during the week?
> This sounds good. I can do some final tests builds over the week end and
> then push it on Monday morning.

Super. I will plan to spend time on Monday to try to walk through it
and see how it goes. I haven't bothered to try yet, so it will be a
good test of the documentation ;)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New Build System Status

[Joel Sherrill]

On Fri, Sep 11, 2020 at 2:00 PM Gedare Bloom  wrote:

> On Fri, Sep 11, 2020 at 12:03 PM Sebastian Huber
>  wrote:
> >
> > On 11/09/2020 17:46, Gedare Bloom wrote:
> >
> > > I have nothing pending. I think we should switch early next week, sort
> > > out any bugs during the week?
> > This sounds good. I can do some final tests builds over the week end and
> > then push it on Monday morning.
>
> Super. I will plan to spend time on Monday to try to walk through it
> and see how it goes. I haven't bothered to try yet, so it will be a
> good test of the documentation ;)
>

Hopefully I can +1 that.

I have someone converting my big cron runner to Python based on the
rtems-tools framework. Switching past autoconf on master will make his
life easier. Basically just autoconf on 5 or waf on master.

--joel


> ___
> 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] Confstr Patches

[Joel Sherrill]

This looks close to me but I see some minor issues. I have tried to
annotate them.

The spacing ones could be spaces vs tabs. Not sure.

On Thu, Sep 10, 2020 at 3:48 PM Eshan dhawan 
wrote:

> Adds Confstr file To RTEMS with test
>
> Signed-off-by: Eshan dhawan 
> ---
>  cpukit/Makefile.am|   1 +
>  cpukit/posix/src/confstr.c| 105 +++
>  testsuites/psxtests/Makefile.am   |   9 ++
>  testsuites/psxtests/configure.ac  |   1 +
>  testsuites/psxtests/psxconfstr/init.c | 125 ++
>  testsuites/psxtests/psxconfstr/psxconfstr.doc |  17 +++
>  testsuites/psxtests/psxconfstr/psxconfstr.scn |   4 +
>  7 files changed, 262 insertions(+)
>  create mode 100644 cpukit/posix/src/confstr.c
>  create mode 100644 testsuites/psxtests/psxconfstr/init.c
>  create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.doc
>  create mode 100644 testsuites/psxtests/psxconfstr/psxconfstr.scn
>
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index e5009e53c9..1c9e4697f1 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -509,6 +509,7 @@ librtemscpu_a_SOURCES += posix/src/condsignalsupp.c
>  librtemscpu_a_SOURCES += posix/src/condtimedwait.c
>  librtemscpu_a_SOURCES += posix/src/condwait.c
>  librtemscpu_a_SOURCES += posix/src/condwaitsupp.c
> +librtemscpu_a_SOURCES += posix/src/confstr.c
>  librtemscpu_a_SOURCES += posix/src/_execve.c
>  librtemscpu_a_SOURCES += posix/src/fork.c
>  librtemscpu_a_SOURCES += posix/src/key.c
> diff --git a/cpukit/posix/src/confstr.c b/cpukit/posix/src/confstr.c
> new file mode 100644
> index 00..71041db462
> --- /dev/null
> +++ b/cpukit/posix/src/confstr.c
> @@ -0,0 +1,105 @@
> +/*-
> + * SPDX-License-Identifier: BSD-3-Clause
> + *
> + * Copyright (c) 1993
> + * The Regents of the University of California.  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.
> + * 3. Neither the name of the University nor the names of its contributors
> + *may be used to endorse or promote products derived from this
> software
> + *without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE REGENTS 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 REGENTS 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.
> + */
> +
> +#include 
> +__SCCSID("@(#)confstr.c8.1 (Berkeley) 6/4/93");
> +__FBSDID("$FreeBSD$");
>

Probably worth adding a comment above that the FreeBSD version
was reduced to what made sense on RTEMS.

+
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>
> If you do that, you won't need all these headers.


> +size_t
> +confstr(int name, char *buf, size_t len)
> +{
> +   const char *p;
> +   const char UPE[] = "unsupported programming environment";
> +
> +   switch (name) {
> +#ifndef __rtems__
> +   case _CS_PATH:
> +   p = _PATH_STDPATH;
> +   goto docopy;
> +#endif
>

It looks like the body of the other cases were gutted from the freebsd
code. Why keep an ifndef RTEMS here? This is just going to produce
an error for an unknown name via the default case. If we are going to
delete all non-FreeBSD code from this and make it a more RTEMS
specific implementation, you might as well just do this:

case _CS_PATH:
  errno = EINVAL;
  return (0);

That keeps the order like the FreeBSD without ifdefs.


> +   /*
> +* POSIX/SUS ``Programming Environments'' stuff
> +*
> +* We don't support more than one programming environment
> +* on any platform (yet), so we just return the empty
> +* string for the environment we are compiled for,
> +* and the string "unsupported programming envir

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[Chris Johns]

On 12/9/20 12:10 am, Joel Sherrill wrote:
> This thread has wandered a lot but I just wanted to say 
> I am OK with the direction this is going.  I think we have
> made this about as safe and easy to use as possible.

Yes.

> Did we decide if there had to be an explicit configure 
> option to even use this API? Chris and I discussed this
> as an idea to force a user to make a very conscious 
> decision to allow it.

Sebastian did not like the idea and accepted that so not at the moment. The
solution is better config management and we will monitor how this goes.

> There does need to be documentation on the allocation
> strategies, when to use, limitations, and particularly the
> use of rtems-exeinfo to get the TLS size. This is one case 
> for sure where an RTEMS Tool needs explicit mention in
> both the API and configure option sections. 

I agree. This one needs a little more than the others.

> I have had flashbacks to how often we got used to get questions 
> about why adding a sleep(1) in the middle of hello world locked
> up. Then we added an option to say "does not need clock
> driver" and the user questions stopped.  I would rather be a 
> bit aggressive on setup and avoid this for tasks with statically
> allocated resources.

I am concerned we have really difficult to debug issues that appear to be bugs
but are weakness in the configuration.

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

Re: New Build System Status

[Chris Johns]

On 12/9/20 5:35 am, Joel Sherrill wrote:
> On Fri, Sep 11, 2020 at 2:00 PM Gedare Bloom  > wrote:
> 
> On Fri, Sep 11, 2020 at 12:03 PM Sebastian Huber
>  > wrote:
> >
> > On 11/09/2020 17:46, Gedare Bloom wrote:
> >
> > > I have nothing pending. I think we should switch early next week, sort
> > > out any bugs during the week?
> > This sounds good. I can do some final tests builds over the week end and
> > then push it on Monday morning.
> 
> Super. I will plan to spend time on Monday to try to walk through it
> and see how it goes. I haven't bothered to try yet, so it will be a
> good test of the documentation ;)
> 
> Hopefully I can +1 that.
> 
> I have someone converting my big cron runner to Python based on the
> rtems-tools framework. Switching past autoconf on master will make his
> life easier. Basically just autoconf on 5 or waf on master.

Should I remove the autotools build set from the default tool builds once the
merge is done?

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

Re: BSP Test Results

[Chris Johns]

On 9/9/20 6:47 pm, Sebastian Huber wrote:
> On 09/09/2020 02:36, Chris Johns wrote:
>> On 9/9/20 3:13 am, Gedare Bloom wrote:
>>> On Sun, Sep 6, 2020 at 8:55 PM Chris Johns  wrote:
 An example using Joel's recent test run (thanks Joel :)). The sparc/leon2
 results show no regressions:

 Summary
 ===

 Passed:    580
 Failed:  0
 User Input:  6
 Expected Fail:   1
>>> Is there a ticket for this one? out of curiosity.
>> I do not think so. This and any others will need to be cleaned up once I
>> implement the change to support ticket numbers. I will do that as part of the
>> change seems I added the expected-fail states.
> 
> I think it is this one:
> 
> http://devel.rtems.org/ticket/3997
> 

Thanks.

> Maybe the expected-fail state should report a ticket number (or link).

Yes. With the ticket number and an internet connection the state of the ticket
can be queried and the subject and state can be used on the test report. For
example the state is expected-fail, the test failed as expected but the ticket
is closed or the other way around the test passes and the ticket is open.

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

Re: BSP Test Results

[Chris Johns]

On 9/9/20 6:49 pm, Sebastian Huber wrote:
> On 09/09/2020 02:29, Chris Johns wrote:
>>> This would be enough to address my "HW or which simulator" question.
>> I had created #4072, please update adding the items you would like. We can 
>> add
>> anything you like and they can be mandated. There already exist a number of
>> fields for various transports so adding this is not hard, creating the list 
>> is
>> harder. These can defined in the .cfg files or they can be part of the user 
>> .ini
>> configuration files and so specific to a user's set up. They would be
>> informational only.
> 
> Before we dig into this, it would be nice to integrate the new build system
> first. We have a lot more options to work with in Python.

Good idea.

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

Re: x86 c++ exception handling

[Chris Johns]

On 12/9/20 12:41 am, Joel Sherrill wrote:
> On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas  > wrote:
> 
> On 9/11/20 3:13 PM, Joel Sherrill wrote:
> > FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced
> > in 1989. The Pentium was 1993. Remember It's All About the Pentium!
> > Pentium II was 1997 and first with SMP but maybe not setting the 
> baseline
> > we want.
> 
> What about to support in master what man can currently purchase? If so,
> then based on my limited research it looks like the cpu family
> (orderable) goes back to 2016/2015 which support architecture of more or
> less NetBurst uarch isn set (both intel and amd).
> 
> One exception found is Vertex86 cpus which still sells and boards are
> available and which are compatible only with i586/p5 from as you noted
> 1993...
> 
> Karel: Typo correction: Vortex86: https://en.wikipedia.org/wiki/Vortex86
> 
> If I am reading that right, we may be ok dumping i386 and i486 completely
> and assuming around a Pentium II as default. Rather than a blanket drop 
> 32-bit support which kills a LOT of usable functionality, I would rather find
> a new floor for the CPU model. 

We have been thinking the BSP is working and technically it is not. I think this
is the issue we should look at first.

Would adding into the BSP a way of detecting and reporting the CPU details be
worth doing? We could then match the specifics of the models to the build of
RTEMS running and if wrong generate a fatal error. This way a user will know if
they have made a mistake selecting a configuration. If there is no configuration
they can report the model and we can take a look. I think this would be better
than an application "almost" working until a specific case like we have with
this thread is hit.

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

Re: [PATCH v4 1/5] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[Chris Johns]

On 12/9/20 1:34 am, Sebastian Huber wrote:
> +const size_t _Thread_Maximum_TLS_size =
> +  CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE;

Should rtems-exeinfo report this?

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

Re: [PATCH v4 2/5] rtems: Add rtems_task_create_from_config()

[Chris Johns]

On 12/9/20 1:34 am, Sebastian Huber wrote:
> + * @par Notes
> + * By default, the calculation for the required memory in the RTEMS Workspace
> + * for tasks assumes that all Classic API Tasks are created by
> + * rtems_task_create().  This configuration option can be used to reduce the
> + * required memory for the system-provided task storage areas since tasks
> + * created by rtems_task_create_from_config() use a user-provided task 
> storage
> + * area.
> + */
> +#define CONFIGURE_TASKS_CREATED_FROM_CONFIG

The documentation does not deal with 0 the default. It is fair to assume a
config that controls allocations for an API is consistent with similar calls. It
I set message queues to 0 any create call fails. I needed to check the patch to
know if 0 meant you could not create any tasks from a config.

If CONFIGURE_TASKS_CREATED_FROM_CONFIG was added to the configuration table
(which I am ok with) the rtems_task_create_from_config() could check for a
non-zero value before proceeding.

> +#ifndef CONFIGURE_TASKS_CREATED_FROM_CONFIG
> +  #define CONFIGURE_TASKS_CREATED_FROM_CONFIG 0
> +#endif
> +
> +#if CONFIGURE_TASKS_CREATED_FROM_CONFIG > CONFIGURE_MAXIMUM_TASKS
> +  #error "CONFIGURE_TASKS_CREATED_FROM_CONFIG shall be less than or equal to 
> CONFIGURE_MAXIMUM_TASKS"
> +#endif
> +
>  #ifndef CONFIGURE_MAXIMUM_POSIX_THREADS
>#define CONFIGURE_MAXIMUM_POSIX_THREADS 0
>  #endif
> diff --git a/cpukit/include/rtems/confdefs/wkspace.h 
> b/cpukit/include/rtems/confdefs/wkspace.h
> index de476dbf82..215cdcb141 100644
> --- a/cpukit/include/rtems/confdefs/wkspace.h
> +++ b/cpukit/include/rtems/confdefs/wkspace.h
> @@ -100,7 +100,9 @@
>  + _CONFIGURE_POSIX_INIT_THREAD_STACK_EXTRA \
>  + _CONFIGURE_LIBBLOCK_TASKS_STACK_EXTRA \
>  + CONFIGURE_EXTRA_TASK_STACKS \
> -+ rtems_resource_maximum_per_allocation( _CONFIGURE_TASKS ) \
> ++ rtems_resource_maximum_per_allocation( \
> +_CONFIGURE_TASKS - CONFIGURE_TASKS_CREATED_FROM_CONFIG \

I am confused by this. Does _CONFIGURE_TASKS have the number of tasks created
from config included in it? How was that added in?

I would have assumed I set CONFIGURE_TASKS_CREATED_FROM_CONFIG and that would be
added _CONFIGURE_TASKS internally.

Sorry, I think I am not understanding something.

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

Re: x86 c++ exception handling

[Joel Sherrill]

On Fri, Sep 11, 2020, 7:29 PM Chris Johns  wrote:

> On 12/9/20 12:41 am, Joel Sherrill wrote:
> > On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas  > > wrote:
> >
> > On 9/11/20 3:13 PM, Joel Sherrill wrote:
> > > FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced
> > > in 1989. The Pentium was 1993. Remember It's All About the Pentium!
> > > Pentium II was 1997 and first with SMP but maybe not setting the
> baseline
> > > we want.
> >
> > What about to support in master what man can currently purchase? If
> so,
> > then based on my limited research it looks like the cpu family
> > (orderable) goes back to 2016/2015 which support architecture of
> more or
> > less NetBurst uarch isn set (both intel and amd).
> >
> > One exception found is Vertex86 cpus which still sells and boards are
> > available and which are compatible only with i586/p5 from as you
> noted
> > 1993...
> >
> > Karel: Typo correction: Vortex86: https://en.wikipedia.org/wiki/Vortex86
> >
> > If I am reading that right, we may be ok dumping i386 and i486 completely
> > and assuming around a Pentium II as default. Rather than a blanket drop
> > 32-bit support which kills a LOT of usable functionality, I would rather
> find
> > a new floor for the CPU model.
>
> We have been thinking the BSP is working and technically it is not. I
> think this
> is the issue we should look at first.
>
> Would adding into the BSP a way of detecting and reporting the CPU details
> be
> worth doing? We could then match the specifics of the models to the build
> of
> RTEMS running and if wrong generate a fatal error. This way a user will
> know if
> they have made a mistake selecting a configuration. If there is no
> configuration
> they can report the model and we can take a look. I think this would be
> better
> than an application "almost" working until a specific case like we have
> with
> this thread is hit.
>

I asked on gcc's mailing list and base i386 has no native atomic
instructions. Unless we are doing something special for that base multilib,
we need to bump up to i486 which does.

That may be sufficient to address this situation.

Broadly speaking I think there is a minimum model for uniprocessor and
another for SMP. Below a certain model SMP did not exist.

No one appears to have a solid technical answer beyond that. The rationale
for Linux was can't buy CPU model in desktop or server in N years. That's
not usually our type of rationale.

I suspect if you want a common floor it is a Pentium II. That's where SMP
appeared.

We can't sanity check the cpu model if we don't know the rules. And if we
know the rules, we should just drop those low models. And error if someone
runs on an older model.


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

rtems_task_create_from_config() Name?

[Joel Sherrill]

Hi

Starting another thread just to discuss this method's name. I wonder if the
config part is more important than the static allocation of resources part.
Which should be emphasized in the name?

>From config puts focus on the attributes part. With static resources or
similar puts emphasis on the other part.

With config is more general but is there another mode of operation? Seems
the static nature is more important and the name should.emohasize that.

Random Friday night thoughts for discussion.

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

Re: pc386 BSP/master branch build failure with smp enabled.

[Gedare Bloom]

On Fri, Sep 11, 2020 at 11:53 AM Karel Gardas  wrote:
>
> On 9/11/20 6:16 PM, Gedare Bloom wrote:
> > Looks to be coming through
> >
> > cpukit/score/cpu/i386/include/rtems/asm.h:157   movb
> > imps_apic_cpu_map(\REG),\REG/* CPU ID in REG */
> >
> > The assembler is right to complain. movb has to target one of the
> > 1-byte mnemonics, so this should be %al for the LSB of %eax. One needs
> > to check through this logic carefully, but I think the right thing to
> > do here is:
> > movzbl imps_apic_cpu_map(\REG),\REG
> >
> > That should do the trick. Can you test it locally?
>
> Sure! Builds fine and testsuite testing reveals:
>
Great. I opened #4076 to apply this fix on 5 branch. It should also go
to master.  I'll try to remember to circle back to this, probably
after the weekend. If anyone wants to generate the patch or gets to it
sooner, great :)


>
> on Ubuntu 18.04 LTS's Qemu 2.11.1:
>
> Passed:625
> Failed:  9
> User Input:  6
> Expected Fail:   0
> Indeterminate:   0
> Benchmark:   3
> Timeout: 5
> Invalid: 7
> Wrong Version:   0
> Wrong Build: 0
> Wrong Tools: 0
> --
> Total: 655
> Failures:
>  dl06.exe
>  psx12.exe
>  psxfenv01.exe
>  smpmulticast01.exe
>  spfatal26.exe
>  spfatal30.exe
>  sptimecounter02.exe
>  tm26.exe
>  tmcontext01.exe
> User Input:
>  dl10.exe
>  monitor.exe
>  termios.exe
>  top.exe
>  capture.exe
>  fileio.exe
> Benchmark:
>  linpack.exe
>  whetstone.exe
>  dhrystone.exe
> Timeouts:
>  dl05.exe
>  ttest02.exe
>  cdtest.exe
>  cxx_iostream.exe
>  smpopenmp01.exe
> Invalid:
>  smpfatal09.exe
>  spfatal06.exe
>  spfatal09.exe
>  spfatal12.exe
>  spinternalerror01.exe
>  spstkalloc02.exe
>  sptimecounter01.exe
> Average test time: 0:00:00.535252
> Testing time : 0:05:50.589935
>
>
> on qemu 5.1.0:
>
> Passed:626
> Failed:  7
> User Input:  6
> Expected Fail:   0
> Indeterminate:   0
> Benchmark:   3
> Timeout: 6
> Invalid: 7
> Wrong Version:   0
> Wrong Build: 0
> Wrong Tools: 0
> --
> Total: 655
> Failures:
>  dl06.exe
>  psx12.exe
>  psxfenv01.exe
>  smpfatal03.exe
>  smpmulticast01.exe
>  spfatal30.exe
>  tmcontext01.exe
> User Input:
>  dl10.exe
>  monitor.exe
>  termios.exe
>  top.exe
>  capture.exe
>  fileio.exe
> Benchmark:
>  linpack.exe
>  whetstone.exe
>  dhrystone.exe
> Timeouts:
>  dl05.exe
>  ttest02.exe
>  cdtest.exe
>  cxx_iostream.exe
>  smpopenmp01.exe
>  spfatal26.exe
> Invalid:
>  smpfatal09.exe
>  spfatal06.exe
>  spfatal09.exe
>  spfatal12.exe
>  spinternalerror01.exe
>  spstkalloc02.exe
>  sptimecounter01.exe
> Average test time: 0:00:00.705858
> Testing time : 0:07:42.336669
>
>
> and finally on qemu 4.2.1:
>
> Passed:627
> Failed:  6
> User Input:  6
> Expected Fail:   0
> Indeterminate:   0
> Benchmark:   3
> Timeout: 6
> Invalid: 7
> Wrong Version:   0
> Wrong Build: 0
> Wrong Tools: 0
> --
> Total: 655
> Failures:
>  dl06.exe
>  psx12.exe
>  psxfenv01.exe
>  smpmulticast01.exe
>  spfatal30.exe
>  tmcontext01.exe
> User Input:
>  dl10.exe
>  monitor.exe
>  termios.exe
>  top.exe
>  capture.exe
>  fileio.exe
> Benchmark:
>  whetstone.exe
>  dhrystone.exe
>  linpack.exe
> Timeouts:
>  dl05.exe
>  ttest02.exe
>  cdtest.exe
>  cxx_iostream.exe
>  smpopenmp01.exe
>  spfatal26.exe
> Invalid:
>  smpfatal09.exe
>  spfatal06.exe
>  spfatal09.exe
>  spfatal12.exe
>  spinternalerror01.exe
>  spstkalloc02.exe
>  sptimecounter01.exe
> Average test time: 0:00:00.705055
> Testing time : 0:07:41.811329
>
>
> >
> > On Fri, Sep 11, 2020 at 6:54 AM Karel Gardas  
> > wrote:
> >>
> >>
> >> Hello,
> >>
> >> I've built 6/rtems-i386 tools using master branch of rtems-source-builder.
> >>
> >> $ i386-rtems6-gcc -v
> >> Using built-in specs.
> >> COLLECT_GCC=i386-rtems6-gcc
> >> COLLECT_LTO_WRAPPER=/export/home/karel/sfw/rtems/6-head-2020-09-11/libexec/gcc/i386-rtems6/10.2.1/lto-wrapper
> >> Target: i386-rtems6
> >> Configured with: ../gnu-mirror-gcc-75f5776/configure
> >> --prefix=/export/home/karel/sfw/rtems/6-head-2020-09-11
> >> --bindir=/export/home/karel/sfw/rtems/6-head-2020-09-11/bin
> >> --exec_prefix=/export/home/karel/sfw/rtems/6-head-2020-09-11
> >> --includedir=/export/home/karel/sfw/rtems/6-head-2020-09-11/include
> >> --libdir=/export/home/karel/sfw/rtems/6-head-2020-09-11/lib
> >> --libexecdir=/export/home/karel/sfw/rtems/6-head-2020-09-11/libexec
> >> --mandir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share/man
> >> --infodir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share/info
> >> --datadir=/export/home/karel/sfw/rtems/6-head-2020-09-11/share
> >> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=i386-rtems6
> >> --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose
> >> --with-newlib --disable-nls --without-included-gettext
> >> --disable-win32-registry --enable-version-specific-runtime-libs
> >> 

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[Gedare Bloom]

On Fri, Sep 11, 2020 at 5:31 PM Chris Johns  wrote:
>
> On 12/9/20 12:10 am, Joel Sherrill wrote:
> > This thread has wandered a lot but I just wanted to say
> > I am OK with the direction this is going.  I think we have
> > made this about as safe and easy to use as possible.
>
> Yes.
>
> > Did we decide if there had to be an explicit configure
> > option to even use this API? Chris and I discussed this
> > as an idea to force a user to make a very conscious
> > decision to allow it.
>
> Sebastian did not like the idea and accepted that so not at the moment. The
> solution is better config management and we will monitor how this goes.
>
> > There does need to be documentation on the allocation
> > strategies, when to use, limitations, and particularly the
> > use of rtems-exeinfo to get the TLS size. This is one case
> > for sure where an RTEMS Tool needs explicit mention in
> > both the API and configure option sections.
>
> I agree. This one needs a little more than the others.
>
> > I have had flashbacks to how often we got used to get questions
> > about why adding a sleep(1) in the middle of hello world locked
> > up. Then we added an option to say "does not need clock
> > driver" and the user questions stopped.  I would rather be a
> > bit aggressive on setup and avoid this for tasks with statically
> > allocated resources.
>
> I am concerned we have really difficult to debug issues that appear to be bugs
> but are weakness in the configuration.
>
There might be something interesting there to solve from an academic
perspective. I should circle back to this thought when it's not almost
midnight on Friday. This seems like a good problem since it's hard to
know for sure the user intent vs what they configured. Some kind of
machine learning / anomaly detection might be useful here.

> Chris
> ___
> 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