RE: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[Jan.Sommer]

> -Original Message-
> From: devel  On Behalf Of Chris Johns
> Sent: Tuesday, February 16, 2021 10:53 PM
> To: Gedare Bloom ; Peter Dufault 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
> 
[...]
> > We haven't really made anything official policy, but I think the rule
> > is to avoid unicode unless there is a good reason for it.
> 
> We do not have a policy and I think we should.
> 
> I looked back and found the only discussion was about the sources for
> documentation:
> 
> https://lists.rtems.org/pipermail/devel/2019-February/052742.html
> 
> After that there is not a lot.
> 
> The doco thread prompted me to check patch 1/3 in this series and saved the
> email. The text in it was a large long box of ascii encoding of some form. I
> applied the patch using git as test and git is fine with this which is neat 
> and
> the unicode characters appeared in the git log as:
> 
> +/*
> + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum fr Luft-
> +und
> Raumfahrt e. V. (DLR)
> + *
> 
> Less and vi both has similar things ...
> 
>  * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum f\xc3\xbcr Luft- und
> Raumfahrt e. V. (DLR)
> 

That's strange. 
I also do my development in terminal. Less, cat and other CLI tools show the 
characters fine.


> The issue for terminal level work discussed in the doco source is present but
> in terms of formal names I am fine with there being unicode characters. I
> think having a formal name written in its proper form is what we should
> allow. The use of unicode in comments or code is different and here we
> need to accept the low common denominator which looks like me on a text
> terminal.
> 

Sounds reasonable to me.

Best regards,

Jan

> 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

RE: [PATCH 1/1] zynq-uart: Fix set_attributes implementation

[Jan.Sommer]

> -Original Message-
> From: Chris Johns 
> Sent: Wednesday, February 10, 2021 12:08 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH 1/1] zynq-uart: Fix set_attributes implementation
> 
> On 9/2/21 11:42 pm, Jan Sommer wrote:
> > From: Kinsey Moore 
> >
> > The zynq-uart set_attributes implementation was configured to always
> > return false which causes spconsole01 to fail. This restores the
> > disabled implementation which sets the baud rate registers
> > appropriately and allows spconsole01 to pass. This also expands the
> > set_attributes functionality to allow setting of the stop bits,
> > character width, and parity.
> 
> Hmmm I missed this change.
> 
> Sebastian changed the Zynq driver to return an error. Returning an error is
> correct because the attributes are not being set however we have a couple
> of design approaches clashing.
> 
> The issue pulls right back to the Xilinx SystemZ design dialogue box. The
> hardware designer has the ability to set the serial port defaults. These
> settings form part of the ps7init data the FSBL paints into the hardware very
> early in the boot process. Also in this data are parallel port pin settings, 
> AXI
> clocks, memory and more so lots of important stuff. The Xilinx bootloader
> and ones I have created (I do not know about uboot) do not touch the UART
> hardware on purpose so the system designer has control. Then in 2017
> Sebastian pushed a change to force the baudrate to a BSP specific default.
> 
> This is normally all OK because all Zynq designs I know of use the default of
> 115200,8,n,1 for the configuration. A problem arises when these defaults are
> varied.
> 
> Maybe something explaining this in the user manual ...
> 
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#xilinx-
> zynq
> 
> so we have provided information on what to change?
> 

Do I understand it correctly, that a patch adding something like the following 
would be sufficient?

Console
---

The console driver for the UARTs of the Zynq SoC will be initialized to a baud 
rate
of 115200 with 8 bit characters, 1 stop bit and no parity bits.
Previous configurations from, e.g., a bootloader will be overwritten.
If a different setting is required, the user application can configure the 
console device
through the standard termios API, e.g. in the init task.

Best regards,

Jan


> The other approach is not to touch the defaults in hardware and allow a get
> attributes to discover them? Does termios drivers have a low level get? I can
> see a set but no get in the zynq uart driver.
> 
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: splinkersets01 test assumptions

[Kinsey Moore]

On 2021/02/17 00:15, Sebastian Huber wrote:
> On 16/02/2021 22:26, Kinsey Moore wrote:
>> In verifying AArch64/ILP32 on hardware I ran across quite a few alignment 
>> issues, some of which were caused by the use of SUBALIGN() in the linker 
>> scripts mentioned here:
>> https://devel.rtems.org/ticket/4178 
>>
>> SUBALIGN() was necessary for two reasons:
>>   * libc sysinit linker sets (this can be fixed in the sysinit handler
>> struct)
>>   * splinkersets01 could not be made to pass on ILP32 as-is without
>> SUBALIGN
>>
> In the ld documentation we have:
>
> https://sourceware.org/binutils/docs/ld/Forced-Input-Alignment.html#index-SUBALIGN_0028subsection_005falign_0029
>
> "You can force input section alignment within an output section by using
> SUBALIGN. The value specified overrides any alignment given by input
> sections, whether larger or smaller."
>
> I think the use of SUBALIGN() is a bug and should be removed. Why do you
> want to override the alignment of the input sections?

I agree. The use of SUBALIGN() removes the trailing padding from the input 
sections used in splinkersets01. The test detects this extra padding as an 
incorrect number of items/incorrect size. It also removes the trailing padding 
from _Sysinit sections which was causing libc init to read every other sysinit 
pointer as NULL.

>> It seems that splinkersets01 makes the assumption that linker sets are 
>> aligned to no more than the size of a pointer. For ILP32, this is not the 
>> case since AArch64 hardware is very sensitive to misaligned accesses and 
>> many structs in linker sections need to be aligned to 8-byte boundaries to 
>> avoid throwing exceptions. Some may even need to be aligned to 16-byte 
>> boundaries depending on the structure, but this doesn't apply to 
>> splinkersets01.
>> The resultant alignment padding causes many assertions in splinkersets01 to 
>> fail.
>>
> The linker sets should use the alignment of the item type. This is done
> by defining zero length arrays:

Within a given input section, the items are packed with the proper alignment. 
Smaller types don't seem to affect the alignment of the linker section within 
the output section which is why SUBALIGN was used. The alignment of linker 
sections within an output section defaults to 8 bytes for both ILP32 and LP64 
on AArch64.

> #define RTEMS_LINKER_ROSET( set, type ) \
>type const RTEMS_LINKER_SET_BEGIN( set )[ 0 ] \
>RTEMS_SECTION( ".rtemsroset." #set ".begin" ) RTEMS_USED; \
>type const RTEMS_LINKER_SET_END( set )[ 0 ] \
>RTEMS_SECTION( ".rtemsroset." #set ".end" ) RTEMS_USED
>
> In standard C such arrays are not defined, but GCC does the right thing:
>
> cat test-linkersets.c
> #define RTEMS_USED __attribute__(( __used__ ))
>
> #define RTEMS_SECTION( _section ) __attribute__(( __section__( _section ) ))
>
> #define RTEMS_LINKER_SET_BEGIN( set ) \
>_Linker_set_##set##_begin
>
> #define RTEMS_LINKER_SET_END( set ) \
>_Linker_set_##set##_end
>
> #define RTEMS_LINKER_ROSET( set, type ) \
>type const RTEMS_LINKER_SET_BEGIN( set )[ 0 ] \
>RTEMS_SECTION( ".rtemsroset." #set ".begin" ) RTEMS_USED; \
>type const RTEMS_LINKER_SET_END( set )[ 0 ] \
>RTEMS_SECTION( ".rtemsroset." #set ".end" ) RTEMS_USED
>
> struct s { __attribute__((__aligned__(256))) int i; };
>
> RTEMS_LINKER_ROSET( i, int );
> RTEMS_LINKER_ROSET( ll, long long );
> RTEMS_LINKER_ROSET( s, struct s );
>
> aarch64-rtems6-gcc -O2 -S -o - test-linkersets.c
>  .arch armv8-a
>  .file   "test-linkersets.c"
>  .text
>  .global _Linker_set_s_end
>  .global _Linker_set_s_begin
>  .global _Linker_set_ll_end
>  .global _Linker_set_ll_begin
>  .global _Linker_set_i_end
>  .global _Linker_set_i_begin
>  .section.rtemsroset.i.begin,"a"
>  .align  3
>  .type   _Linker_set_i_begin, %object
>  .size   _Linker_set_i_begin, 0
> _Linker_set_i_begin:
>  .section.rtemsroset.i.end,"a"
>  .align  3
>  .type   _Linker_set_i_end, %object
>  .size   _Linker_set_i_end, 0
> _Linker_set_i_end:
>  .section.rtemsroset.ll.begin,"a"
>  .align  3
>  .type   _Linker_set_ll_begin, %object
>  .size   _Linker_set_ll_begin, 0
> _Linker_set_ll_begin:
>  .section.rtemsroset.ll.end,"a"
>  .align  3
>  .type   _Linker_set_ll_end, %object
>  .size   _Linker_set_ll_end, 0
> _Linker_set_ll_end:
>  .section.rtemsroset.s.begin,"a"
>  .align  8
>  .type   _Linker_set_s_begin, %object
>  .size   _Linker_set_s_begin, 0
> _Linker_set_s_begin:
>  .section.rtemsroset.s.end,"a"
>  .align  8
>  .type   _Linker_set_s_end, %object
>  .size   _Linker_set_s_end, 0
> _Linker_set_s_end:
>  .ident  "GCC: (GNU) 10.2.1 20210205 (RTEMS 6, RSB
> 61dcad

Re: splinkersets01 test assumptions

[Sebastian Huber]

On 17/02/2021 16:32, Kinsey Moore wrote:

  .section.rtemsroset.s.begin,"a"
  .align  8
  .type   _Linker_set_s_begin, %object
  .size   _Linker_set_s_begin, 0
_Linker_set_s_begin:
  .section.rtemsroset.s.end,"a"
  .align  8
  .type   _Linker_set_s_end, %object
  .size   _Linker_set_s_end, 0
_Linker_set_s_end:
  .ident  "GCC: (GNU) 10.2.1 20210205 (RTEMS 6, RSB
61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f)"




I would remove the SUBALIGN() from the linker script. You can also add a
new test case for splinkersets01 similar to struct s from above. Then we
should check if the test fails on aarch64 and why it fails.

The example above actually shows the issue I'm having in _Linker_set_i_begin 
and _Linker_set_i_end. The alignment expands for the larger struct, but does 
not shrink for data types smaller than 8 bytes, leaving padding that the test 
interprets as additional space in the linker set.
I still don't see why a larger alignment is an issue. The begin/end 
objects have a size of zero. Where do you observe a padding?


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: [PATCH 1/1] misc: tools: fix mkimage.py script type processing

[Gedare Bloom]

On Wed, Feb 17, 2021 at 12:35 AM  wrote:
>
> Hi Chris,
>
> as far as my understanding of python goes this does not make any difference.
> Strings are essentially arrays in python which would make the parenthesis 
> obsolete.
>
> When this condition should catch another type in the future it would be good 
> practice to do something like this:
>
> If options.type in ['script', '']:
>
> Even though the following would be functional the same but obviously much 
> less readable and logical:
>
> If options.type in 'script':
>
I don't quite agree.

$ python3
Python 3.8.5 (default, Jul 28 2020, 12:59:40)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ff='s'
>>> if ff in 'script':
...   print("blah")
...
blah
>>> if ff in ['script']:
...   print("blah")
...
>>>

You need the list, or else the "in" operator iterates the string as a
character checking for membership, which can match on single
characters. Only if you can guarantee options.type is also a string
can you omit the list tokens. It is also more future-proof for adding
other options.

> Best regards
> André
>
> -Ursprüngliche Nachricht-
> Von: Chris Johns 
> Gesendet: Dienstag, 16. Februar 2021 21:29
> An: Sommer, Jan ; devel@rtems.org
> Cc: Nahrwold, Andre 
> Betreff: Re: [PATCH 1/1] misc: tools: fix mkimage.py script type processing
>
> On 12/2/21 3:23 am, Jan Sommer wrote:
> > From: Andre Nahrwold 
> >
> > ---
> >  misc/tools/mkimage.py | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py index
> > fd75f0a..111e224 100755
> > --- a/misc/tools/mkimage.py
> > +++ b/misc/tools/mkimage.py
> > @@ -121,6 +121,16 @@ outputfile.seek(struct.size);
> >
> >  inputcrc = 0;
> >
> > +if options.type in 'script':
>
> I saw this and thought it might be wrong and now I think it is. Should this 
> line be:
>
>  > +if options.type in ['script']:
>
> ?
>
> 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

RE: splinkersets01 test assumptions

[Kinsey Moore]

> On 17/02/2021 16:32, Kinsey Moore wrote:
>>>   .section.rtemsroset.s.begin,"a"
>>>   .align  8
>>>   .type   _Linker_set_s_begin, %object
>>>   .size   _Linker_set_s_begin, 0
>>> _Linker_set_s_begin:
>>>   .section.rtemsroset.s.end,"a"
>>>   .align  8
>>>   .type   _Linker_set_s_end, %object
>>>   .size   _Linker_set_s_end, 0
>>> _Linker_set_s_end:
>>>   .ident  "GCC: (GNU) 10.2.1 20210205 (RTEMS 6, RSB
>>> 61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f)"
 

>>> I would remove the SUBALIGN() from the linker script. You can also add a
>>> new test case for splinkersets01 similar to struct s from above. Then we
>>> should check if the test fails on aarch64 and why it fails.
>> The example above actually shows the issue I'm having in _Linker_set_i_begin 
>> and _Linker_set_i_end. The alignment expands for the larger struct, but does 
>> not shrink for data types smaller than 8 bytes, leaving padding that the 
>> test interprets as additional space in the linker set.
>
> I still don't see why a larger alignment is an issue. The begin/end 
> objects have a size of zero. Where do you observe a padding?

Even when the begin/end objects have a size of 0, they're aligned out to 8 
bytes forcing empty bytes if the content does not exactly fill a multiple of 8 
bytes. Those non-content bytes are counted as part of the section.

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

Re: [PATCH v2 12/12] c-user: Generate clock manager documentation

[Sebastian Huber]

On 11/02/2021 14:31, Frank Kühndel wrote:


+rtems_status_code rtems_clock_set( const rtems_time_of_day *time );

A comment only: The above is a change in the signature of the function
(adding `const`). Not that I object to it - on the contrary. Yet, it may
break existing code (e.g. code which uses function pointers to
rtems_clock_set() maybe). Not sure how the project deals with such
changes in the API.
It is good to notice this. In this case, it is just a documentation fix 
thanks to the generated content. The API change was in RTEMS 4.11.


Note: You renamed this parameter to `time` but you renamed the parameter
of rtems_clock_get_tod() to `time_of_day`.


I will change both parameters to time_of_day.

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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: splinkersets01 test assumptions

[Sebastian Huber]

On 17/02/2021 17:41, Kinsey Moore wrote:


I would remove the SUBALIGN() from the linker script. You can also add a
new test case for splinkersets01 similar to struct s from above. Then we
should check if the test fails on aarch64 and why it fails.

The example above actually shows the issue I'm having in _Linker_set_i_begin 
and _Linker_set_i_end. The alignment expands for the larger struct, but does 
not shrink for data types smaller than 8 bytes, leaving padding that the test 
interprets as additional space in the linker set.

I still don't see why a larger alignment is an issue. The begin/end
objects have a size of zero. Where do you observe a padding?

Even when the begin/end objects have a size of 0, they're aligned out to 8 
bytes forcing empty bytes if the content does not exactly fill a multiple of 8 
bytes. Those non-content bytes are counted as part of the section.


Ok, it took a while, but I understand now the problem. I think this is a 
GCC bug.


cat test-align.c
char i;
char j[1];
char z[0];
unsigned long ai = _Alignof(i);
unsigned long aj = _Alignof(j);
unsigned long az = _Alignof(z);

aarch64-rtems6-gcc -O2 -S -o - test-align.c -mabi=ilp32 -fdata-sections
    .arch armv8-a
    .file   "test-align.c"
    .text
    .global az
    .global aj
    .global ai
    .global z
    .global j
    .global i
    .section    .bss.i,"aw",@nobits
    .type   i, %object
    .size   i, 1
i:
    .zero   1
    .section    .bss.j,"aw",@nobits
    .align  3
    .type   j, %object
    .size   j, 1
j:
    .zero   1
    .section    .bss.z,"aw",@nobits
    .align  3
    .type   z, %object
    .size   z, 0
z:
    .section    .data.ai,"aw"
    .align  2
    .type   ai, %object
    .size   ai, 4
ai:
    .word   1
    .section    .data.aj,"aw"
    .align  2
    .type   aj, %object
    .size   aj, 4
aj:
    .word   1
    .section    .data.az,"aw"
    .align  2
    .type   az, %object
    .size   az, 4
az:
    .word   1
    .ident  "GCC: (GNU) 10.2.1 20210205 (RTEMS 6, RSB 
61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f)"


clang --target=aarch64 -O2 -S -o - test-align.c  -fdata-sections -fno-common
test-align.c:4:20: warning: '_Alignof' applied to an expression is a GNU 
extension [-Wgnu-alignof-expression]

unsigned long ai = _Alignof(i);
   ^
test-align.c:5:20: warning: '_Alignof' applied to an expression is a GNU 
extension [-Wgnu-alignof-expression]

unsigned long aj = _Alignof(j);
   ^
test-align.c:6:20: warning: '_Alignof' applied to an expression is a GNU 
extension [-Wgnu-alignof-expression]

unsigned long az = _Alignof(z);
   ^
    .text
    .file   "test-align.c"
    .type   ai,@object  // @ai
    .section    .data.ai,"aw",@progbits
    .globl  ai
    .p2align    3
ai:
    .xword  1   // 0x1
    .size   ai, 8

    .type   aj,@object  // @aj
    .section    .data.aj,"aw",@progbits
    .globl  aj
    .p2align    3
aj:
    .xword  1   // 0x1
    .size   aj, 8

    .type   az,@object  // @az
    .section    .data.az,"aw",@progbits
    .globl  az
    .p2align    3
az:
    .xword  1   // 0x1
    .size   az, 8

    .type   i,@object   // @i
    .section    .bss.i,"aw",@nobits
    .globl  i
i:
    .byte   0   // 0x0
    .size   i, 1

    .type   j,@object   // @j
    .section    .bss.j,"aw",@nobits
    .globl  j
j:
    .zero   1
    .size   j, 1

    .type   z,@object   // @z
    .section    .bss.z,"aw",@nobits
    .globl  z
z:
    .size   z, 0


    .ident  "clang version 9.0.1 "
    .section    ".note.GNU-stack","",@progbits
    .addrsig
3 warnings generated.

I would file a GCC bug report.

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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: [PATCH v2 00/12] Generate documentation for managers

[Sebastian Huber]

On 10/02/2021 21:33, Gedare Bloom wrote:



On Wed, Feb 10, 2021 at 9:46 AM Sebastian Huber 
> wrote:


On 10/02/2021 17:42, Gedare Bloom wrote:

> Is (will be) there a section to explain the Constraints and how to
> interpret them? Mainly, what kind of constraints are specified, and
> what should be assumed (like, if a directive does not say it can be
> called from thread context, then it implicitly cannot)?
On my high priority TODO list is the generation of the message
manager,
task manager, scheduler concepts, interrupt manager, and
rate-monotonic
manager documentation. Once this is done we will have a good
overview of
the constraints. I would like to add a "Directive Constraints"
section
to the "Key Concepts" chapter.

ok, I read the other patches they looked alright (without a deep analysis)
Thanks, I checked in the patches today. I will now check in the 
generated header files. The have the same documentation content.


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Coverity Reports on Passing NULL to fileno()

[Joel Sherrill]

Hi

Ryan has been investigating some Coverity reports where fileno(FILE *)
could be passed a NULL. I asked about adding a NULL check in newlib and was
reminded that POSIX leaves passing a NULL pointer as undefined behavior.

I don't want to ignore calls to fileno() and other methods from RTEMS code
that potentially could pass a NULL in. I only see a few options:

  + Use an rtems_fileno() wrapper which does check for NULL. I don't like
this because it opens a path of doing this for any libc method that takes a
pointer.

+ Mark these as ignored in Coverity. I don't like this because it always
feels like we could be papering over something.

+ Add an RTEMS assert() ahead of these suspect calls so at least debug mode
flags them and Coverity is happier.

+ Add nonnull attribute to the headers for the various parameters in libc
that shouldn't be null. I don't think this will catch all stupid cases of
passing NULL but may be sufficient to catch some. I have no idea if this
will make Coverity happy or not.

I think aiming for the last two since they seem reasonable and
straightforward.

Other ideas?

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

Re: Coverity Reports on Passing NULL to fileno()

[Sebastian Huber]

On 17/02/2021 18:58, Joel Sherrill wrote:



I don't want to ignore calls to fileno() and other methods from RTEMS 
code that potentially could pass a NULL in. I only see a few options:


  + Use an rtems_fileno() wrapper which does check for NULL. I don't 
like this because it opens a path of doing this for any libc method 
that takes a pointer.


+ Mark these as ignored in Coverity. I don't like this because it 
always feels like we could be papering over something.


+ Add an RTEMS assert() ahead of these suspect calls so at least debug 
mode flags them and Coverity is happier.


+ Add nonnull attribute to the headers for the various parameters in 
libc that shouldn't be null. I don't think this will catch all stupid 
cases of passing NULL but may be sufficient to catch some. I have no 
idea if this will make Coverity happy or not.


I think aiming for the last two since they seem reasonable and 
straightforward.


The nonnull attribute could have unpleasant side effects:

http://www.rkoucha.fr/tech_corner/nonnull_gcc_attribute.html

I would place assertions in the code. This looks like a case by case 
analysis is necessary.


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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

Re: Coverity Reports on Passing NULL to fileno()

[Gedare Bloom]

On Wed, Feb 17, 2021 at 11:21 AM Sebastian Huber
 wrote:
>
> On 17/02/2021 18:58, Joel Sherrill wrote:
>
> >
> > I don't want to ignore calls to fileno() and other methods from RTEMS
> > code that potentially could pass a NULL in. I only see a few options:
> >
> >   + Use an rtems_fileno() wrapper which does check for NULL. I don't
> > like this because it opens a path of doing this for any libc method
> > that takes a pointer.
> >
> > + Mark these as ignored in Coverity. I don't like this because it
> > always feels like we could be papering over something.
> >
> > + Add an RTEMS assert() ahead of these suspect calls so at least debug
> > mode flags them and Coverity is happier.
> >
> > + Add nonnull attribute to the headers for the various parameters in
> > libc that shouldn't be null. I don't think this will catch all stupid
> > cases of passing NULL but may be sufficient to catch some. I have no
> > idea if this will make Coverity happy or not.
> >
> > I think aiming for the last two since they seem reasonable and
> > straightforward.
>
> The nonnull attribute could have unpleasant side effects:
>
> http://www.rkoucha.fr/tech_corner/nonnull_gcc_attribute.html
>
> I would place assertions in the code. This looks like a case by case
> analysis is necessary.
>
I agree, I'd just put an assert before the call. I don't think a
wrapper is necessary, unless we do need to add this to other
libc/posix functions

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

Project Status: #3333

[Dev Agrawal]

Hello,
I went through the list of open projects and found project.
#   Automate Conversion of Newlib
Markup to Sphinx
I would be very grateful to know the work done/needed to be done in it.

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

Re: [PATCH 1/1] misc: tools: fix mkimage.py script type processing

[Chris Johns]

On 18/2/21 3:26 am, Gedare Bloom wrote:
> On Wed, Feb 17, 2021 at 12:35 AM  wrote:
>>
>> Hi Chris,
>>
>> as far as my understanding of python goes this does not make any difference.
>> Strings are essentially arrays in python which would make the parenthesis 
>> obsolete.
>>
>> When this condition should catch another type in the future it would be good 
>> practice to do something like this:
>>
>> If options.type in ['script', '']:
>>
>> Even though the following would be functional the same but obviously much 
>> less readable and logical:
>>
>> If options.type in 'script':
>>
> I don't quite agree.
> 
> $ python3
> Python 3.8.5 (default, Jul 28 2020, 12:59:40)
> [GCC 9.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 ff='s'
 if ff in 'script':
> ...   print("blah")
> ...
> blah
 if ff in ['script']:
> ...   print("blah")
> ...

> 
> You need the list, or else the "in" operator iterates the string as a
> character checking for membership, which can match on single
> characters. Only if you can guarantee options.type is also a string
> can you omit the list tokens. It is also more future-proof for adding
> other options.

Thanks for this. The match also covers substrings so characters match and
strings like `cr` or `ipt` also match and this is not what we want.

>>> s = 'c'






>>> if s in 'script':
... print('blah')






...
blah
>>> s = 'cr'






>>> if s in 'script':
... print('blah')






...
blah
>>> s = 'ipt'






>>> if s in 'script':
... print('blah')






...
blah

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

[PATCH] c-user: Generate signal manager documentation

[Sebastian Huber]

The documentation is a consolidation of the comments in Doxygen markup
and the documentation sources in Sphinx markup.  The documentation was
transfered to interface specification items.  The documentation source
files were generated from the items by a script.

Update #3993.
---
 c-user/signal/directives.rst   | 288 -
 c-user/signal/introduction.rst |  33 +++-
 2 files changed, 209 insertions(+), 112 deletions(-)

diff --git a/c-user/signal/directives.rst b/c-user/signal/directives.rst
index 2479681..b883b0a 100644
--- a/c-user/signal/directives.rst
+++ b/c-user/signal/directives.rst
@@ -1,126 +1,198 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
+.. Copyright (C) 2020, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
+.. This file is part of the RTEMS quality process and was automatically
+.. generated.  If you find something that needs to be fixed or
+.. worded better please post a report or patch to an RTEMS mailing list
+.. or raise a bug report:
+..
+.. https://www.rtems.org/bugs.html
+..
+.. For information on updating and regenerating please refer to the How-To
+.. section in the Software Requirements Engineering chapter of the
+.. RTEMS Software Engineering manual.  The manual is provided as a part of
+.. a release.  For development sources please refer to the online
+.. documentation at:
+..
+.. https://docs.rtems.org
+
+.. _SignalManagerDirectives:
+
 Directives
 ==
 
-This section details the signal manager's directives.  A subsection is
-dedicated to each of this manager's directives and describes the calling
-sequence, related constants, usage, and status codes.
+This section details the directives of the Signal Manager. A subsection is
+dedicated to each of this manager's directives and lists the calling sequence,
+parameters, description, return values, and notes of the directive.
+
+.. Generated from spec:/rtems/signal/if/catch
 
 .. raw:: latex
 
-   \clearpage
+\clearpage
 
+.. index:: rtems_signal_catch()
 .. index:: establish an ASR
 .. index:: install an ASR
-.. index:: rtems_signal_catch
-
-.. _rtems_signal_catch:
-
-SIGNAL_CATCH - Establish an ASR

-
-CALLING SEQUENCE:
-.. code-block:: c
-
-rtems_status_code rtems_signal_catch(
-rtems_asr_entry  asr_handler,
-rtems_mode   mode
-);
-
-DIRECTIVE STATUS CODES:
-.. list-table::
- :class: rtems-table
-
- * - ``RTEMS_SUCCESSFUL``
-   - always successful
-
-DESCRIPTION:
-This directive establishes an asynchronous signal routine (ASR) for the
-calling task.  The asr_handler parameter specifies the entry point of the
-ASR.  If asr_handler is NULL, the ASR for the calling task is invalidated
-and all pending signals are cleared.  Any signals sent to a task with an
-invalid ASR are discarded.  The mode parameter specifies the execution mode
-for the ASR.  This execution mode supersedes the task's execution mode
-while the ASR is executing.
-
-NOTES:
-This directive will not cause the calling task to be preempted.
-
-The following task mode constants are defined by RTEMS:
-
-.. list-table::
- :class: rtems-table
-
- * - ``RTEMS_PREEMPT``
-   - is masked by ``RTEMS_PREEMPT_MASK`` and enables preemption
- * - ``RTEMS_NO_PREEMPT``
-   - is masked by ``RTEMS_PREEMPT_MASK`` and disables preemption
- * - ``RTEMS_NO_TIMESLICE``
-   - is masked by ``RTEMS_TIMESLICE_MASK`` and disables timeslicing
- * - ``RTEMS_TIMESLICE``
-   - is masked by ``RTEMS_TIMESLICE_MASK`` and enables timeslicing
- * - ``RTEMS_ASR``
-   - is masked by ``RTEMS_ASR_MASK`` and enables ASR processing
- * - ``RTEMS_NO_ASR``
-   - is masked by ``RTEMS_ASR_MASK`` and disables ASR processing
- * - ``RTEMS_INTERRUPT_LEVEL(0)``
-   - is masked by ``RTEMS_INTERRUPT_MASK`` and enables all interrupts
- * - ``RTEMS_INTERRUPT_LEVEL(n)``
-   - is masked by ``RTEMS_INTERRUPT_MASK`` and sets interrupts level n
+
+.. _InterfaceRtemsSignalCatch:
+
+rtems_signal_catch()
+
+
+Establishes an asynchronous signal routine (ASR) for the calling task.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+rtems_status_code rtems_signal_catch(
+  rtems_asr_entry asr_handler,
+  rtems_mode  mode_set
+);
+
+.. rubric:: PARAMETERS:
+
+``asr_handler``
+This parameter is the handler to process an asynchronous signal set.
+
+``mode_set``
+This parameter is the task mode while an asynchronous signal set is
+processed by the handler.  See :ref:`InterfaceRtemsTaskMode`.
+
+.. rubric:: DESCRIPTION:
+
+This directive establishes an asynchronous signal routine (ASR) for the calling
+task.  The ``asr_handler`` parameter specifies the entry point of the ASR.  A
+task may have at most one handler installed at a time.  The most recently

[PATCH 00/13] Avoid potential recursion in ASR handling

[Sebastian Huber]

This patch set adds validation tests for the signal manager and fixes a
potential issue with a recursion in the ASR handling.  The main issue is
that _Signal_Action_handler() used rtems_task_mode() to save, set, and
restore the task mode during ASR processing.  This is effectively a
recursive call to thread dispatching which may result in the next level
of ASR processing.

Sebastian Huber (13):
  validation: Add Validation1 test suite
  validation: Add signal manager tests
  score: Change thread action locking
  score: Add _Thread_Append_post_switch_action()
  posix: Remove superfluous check
  rtems: Remove unused _Modes_Mask_changed()
  rtems: Remove unused _Modes_Change()
  rtems: Remove unused ASR_Information::nest_level
  rtems: Move _Signal_Action_handler()
  rtems: Simplify signal handling
  rtems: New errors for rtems_signal_catch()
  rtems: Add _Modes_Set_timeslice()
  rtems: Avoid potential recursion in ASR handling

 cpukit/headers.am |1 -
 cpukit/include/rtems/rtems/asrdata.h  |4 -
 cpukit/include/rtems/rtems/asrimpl.h  |   90 --
 cpukit/include/rtems/rtems/modesimpl.h|   47 +-
 cpukit/include/rtems/rtems/signalimpl.h   |   10 -
 cpukit/include/rtems/score/thread.h   |   19 +-
 cpukit/include/rtems/score/threadimpl.h   |   38 +-
 cpukit/posix/src/psignalunblockthread.c   |8 +-
 cpukit/rtems/src/signalcatch.c|   99 +-
 cpukit/rtems/src/signalsend.c |  132 +-
 cpukit/rtems/src/taskmode.c   |   32 +-
 cpukit/score/src/threaddispatch.c |3 -
 spec/build/bsps/tstsmallmem.yml   |1 +
 spec/build/cpukit/librtemscpu.yml |1 -
 spec/build/testsuites/validation/grp.yml  |2 +
 .../testsuites/validation/validation-0.yml|2 +
 .../testsuites/validation/validation-1.yml|   21 +
 testsuites/validation/tc-signal-catch.c   | 1017 +++
 testsuites/validation/tc-signal-send.c| 1146 +
 testsuites/validation/ts-default.h|4 +-
 testsuites/validation/ts-validation-0.c   |4 +-
 testsuites/validation/ts-validation-1.c   |   75 ++
 22 files changed, 2505 insertions(+), 251 deletions(-)
 delete mode 100644 cpukit/include/rtems/rtems/asrimpl.h
 create mode 100644 spec/build/testsuites/validation/validation-1.yml
 create mode 100644 testsuites/validation/tc-signal-catch.c
 create mode 100644 testsuites/validation/tc-signal-send.c
 create mode 100644 testsuites/validation/ts-validation-1.c

-- 
2.26.2

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

[PATCH 03/13] score: Change thread action locking

[Sebastian Huber]

Require that the corresponding lock is acquired before the action
handler returns.  This helps to avoid recursion in the signal
processing.

Update #4244.
---
 cpukit/include/rtems/score/thread.h | 19 +++
 cpukit/posix/src/psignalunblockthread.c |  2 ++
 cpukit/rtems/src/signalcatch.c  |  6 --
 cpukit/score/src/threaddispatch.c   |  3 ---
 4 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/cpukit/include/rtems/score/thread.h 
b/cpukit/include/rtems/score/thread.h
index 0920a44177..e23261701a 100644
--- a/cpukit/include/rtems/score/thread.h
+++ b/cpukit/include/rtems/score/thread.h
@@ -594,20 +594,23 @@ typedef enum {
 typedef struct Thread_Action Thread_Action;
 
 /**
- * @brief Thread action handler.
+ * @brief This type defines the prototype of thread action handlers.
  *
  * The thread action handler will be called with interrupts disabled and a
- * corresponding lock acquired, e.g. _Thread_State_acquire().  The handler must
- * release the corresponding lock, e.g. _Thread_State_release().  So, the
- * corresponding lock may be used to protect private data used by the
- * particular action.
+ * corresponding lock acquired, e.g. _Thread_State_acquire().  The handler may
+ * release the corresponding lock, e.g. _Thread_State_release().  If the lock
+ * is released, it shall be acquired before the handler returns using the lock
+ * context.  The lock may be used to protect private data used by the action.
  *
  * Since the action is passed to the handler additional data may be accessed
  * via RTEMS_CONTAINER_OF().
  *
- * @param[in] the_thread The thread performing the action.
- * @param[in] action The thread action.
- * @param[in] lock_context The lock context to use for the lock release.
+ * @param[in, out] the_thread is the thread performing the action.
+ *
+ * @param[in, out] action is the thread action.
+ *
+ * @param[in, out] lock_context is the lock context to use for the optional
+ *   lock release and acquire.
  */
 typedef void ( *Thread_Action_handler )(
   Thread_Control   *the_thread,
diff --git a/cpukit/posix/src/psignalunblockthread.c 
b/cpukit/posix/src/psignalunblockthread.c
index 80a0f33a09..63ed823ab3 100644
--- a/cpukit/posix/src/psignalunblockthread.c
+++ b/cpukit/posix/src/psignalunblockthread.c
@@ -159,6 +159,8 @@ static void _POSIX_signals_Action_handler(
   }
 
   executing->Wait.return_code = hold_errno;
+
+  _Thread_State_acquire( executing, lock_context );
 }
 
 static bool _POSIX_signals_Unblock_thread_done(
diff --git a/cpukit/rtems/src/signalcatch.c b/cpukit/rtems/src/signalcatch.c
index c59e132ad3..2fd7c13374 100644
--- a/cpukit/rtems/src/signalcatch.c
+++ b/cpukit/rtems/src/signalcatch.c
@@ -51,12 +51,12 @@ void _Signal_Action_handler(
   asr = &api->Signal;
   signal_set = _ASR_Get_posted_signals( asr );
 
-  _Thread_State_release( executing, lock_context );
-
   if ( signal_set == 0 ) {
 return;
   }
 
+  _Thread_State_release( executing, lock_context );
+
   asr->nest_level += 1;
   rtems_task_mode( asr->mode_set, RTEMS_ALL_MODE_MASKS, &prev_mode );
 
@@ -64,6 +64,8 @@ void _Signal_Action_handler(
 
   asr->nest_level -= 1;
   rtems_task_mode( prev_mode, RTEMS_ALL_MODE_MASKS, &prev_mode );
+
+  _Thread_State_acquire( executing, lock_context );
 }
 
 rtems_status_code rtems_signal_catch(
diff --git a/cpukit/score/src/threaddispatch.c 
b/cpukit/score/src/threaddispatch.c
index c4dadc0ff1..bae2902bda 100644
--- a/cpukit/score/src/threaddispatch.c
+++ b/cpukit/score/src/threaddispatch.c
@@ -249,10 +249,7 @@ static void _Thread_Run_post_switch_actions( 
Thread_Control *executing )
 
   while ( action != NULL ) {
 _Chain_Set_off_chain( &action->Node );
-
 ( *action->handler )( executing, action, &lock_context );
-
-_Thread_State_acquire( executing, &lock_context );
 action = _Thread_Get_post_switch_action( executing );
   }
 
-- 
2.26.2

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

[PATCH 12/13] rtems: Add _Modes_Set_timeslice()

[Sebastian Huber]

Update #4244.
---
 cpukit/include/rtems/rtems/modesimpl.h | 15 +++
 cpukit/rtems/src/taskmode.c|  8 +---
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/cpukit/include/rtems/rtems/modesimpl.h 
b/cpukit/include/rtems/rtems/modesimpl.h
index 5677c7f13d..f6711b4c2d 100644
--- a/cpukit/include/rtems/rtems/modesimpl.h
+++ b/cpukit/include/rtems/rtems/modesimpl.h
@@ -20,6 +20,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
@@ -99,6 +101,19 @@ RTEMS_INLINE_ROUTINE void _Modes_Set_interrupt_level (
   _ISR_Set_level( _Modes_Get_interrupt_level( mode_set ) );
 }
 
+RTEMS_INLINE_ROUTINE void _Modes_Set_timeslice(
+  Thread_Control *executing,
+  rtems_mode  mode_set
+)
+{
+  if ( _Modes_Is_timeslice( mode_set ) ) {
+executing->budget_algorithm = THREAD_CPU_BUDGET_ALGORITHM_RESET_TIMESLICE;
+executing->cpu_time_budget = rtems_configuration_get_ticks_per_timeslice();
+  } else {
+executing->budget_algorithm = THREAD_CPU_BUDGET_ALGORITHM_NONE;
+  }
+}
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/cpukit/rtems/src/taskmode.c b/cpukit/rtems/src/taskmode.c
index 24905368c3..197f5e1556 100644
--- a/cpukit/rtems/src/taskmode.c
+++ b/cpukit/rtems/src/taskmode.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 
 rtems_status_code rtems_task_mode(
   rtems_mode  mode_set,
@@ -104,12 +103,7 @@ rtems_status_code rtems_task_mode(
   }
 
   if ( mask & RTEMS_TIMESLICE_MASK ) {
-if ( _Modes_Is_timeslice(mode_set) ) {
-  executing->budget_algorithm = 
THREAD_CPU_BUDGET_ALGORITHM_RESET_TIMESLICE;
-  executing->cpu_time_budget =
-rtems_configuration_get_ticks_per_timeslice();
-} else
-  executing->budget_algorithm = THREAD_CPU_BUDGET_ALGORITHM_NONE;
+_Modes_Set_timeslice( executing, mode_set );
   }
 
   /*
-- 
2.26.2

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

[PATCH 13/13] rtems: Avoid potential recursion in ASR handling

[Sebastian Huber]

Do the mode changes necessary for the ASR processing directly under
protection of the thread state lock to avoid the recursive calls to
thread dispatching done in rtems_task_mode().

Update #4244.
---
 cpukit/rtems/src/signalsend.c | 89 ---
 1 file changed, 82 insertions(+), 7 deletions(-)

diff --git a/cpukit/rtems/src/signalsend.c b/cpukit/rtems/src/signalsend.c
index 606ddfcb53..dd2f70ec53 100644
--- a/cpukit/rtems/src/signalsend.c
+++ b/cpukit/rtems/src/signalsend.c
@@ -21,7 +21,9 @@
 #endif
 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 
@@ -33,10 +35,17 @@ static void _Signal_Action_handler(
   ISR_lock_Context *lock_context
 )
 {
-  RTEMS_API_Control *api;
-  ASR_Information   *asr;
-  rtems_signal_set   signal_set;
-  rtems_mode  prev_mode;
+  RTEMS_API_Control   *api;
+  ASR_Information *asr;
+  rtems_signal_set signal_set;
+  bool normal_is_preemptible;
+  uint32_t normal_cpu_time_budget;
+  Thread_CPU_budget_algorithms normal_budget_algorithm;
+  bool normal_asr_is_enabled;
+  uint32_t normal_isr_level;
+  uint32_t asr_isr_level;
+  bool prev_is_preemptible;
+  bool prev_asr_is_enabled;
 
   (void) action;
 
@@ -48,16 +57,82 @@ static void _Signal_Action_handler(
   _Assert( signal_set != 0 );
   asr->signals_pending = 0;
 
-  _Thread_State_release( executing, lock_context );
+  /* Save normal mode */
+
+  normal_is_preemptible = executing->is_preemptible;
+  normal_asr_is_enabled = asr->is_enabled;
+  normal_cpu_time_budget = executing->cpu_time_budget;
+  normal_budget_algorithm = executing->budget_algorithm;
+
+  /* Set mode for ASR processing */
+
+  executing->is_preemptible = _Modes_Is_preempt( asr->mode_set );
+  asr->is_enabled = !_Modes_Is_asr_disabled( asr->mode_set );
+  _Modes_Set_timeslice( executing, asr->mode_set );
+  asr_isr_level = _Modes_Get_interrupt_level( asr->mode_set );
 
-  rtems_task_mode( asr->mode_set, RTEMS_ALL_MODE_MASKS, &prev_mode );
+  if ( executing->is_preemptible && !normal_is_preemptible ) {
+Per_CPU_Control *cpu_self;
+
+cpu_self = _Thread_Dispatch_disable_critical( lock_context );
+_Scheduler_Schedule( executing );
+_Thread_State_release( executing, lock_context );
+_Thread_Dispatch_direct( cpu_self );
+  } else {
+_Thread_State_release( executing, lock_context );
+  }
+
+  normal_isr_level = _ISR_Get_level();
+  _ISR_Set_level( asr_isr_level );
 
   /* Call the ASR handler in the ASR processing mode */
   ( *asr->handler )( signal_set );
 
-  rtems_task_mode( prev_mode, RTEMS_ALL_MODE_MASKS, &prev_mode );
+  /* Restore normal mode */
+
+  _ISR_Set_level( normal_isr_level );
 
   _Thread_State_acquire( executing, lock_context );
+
+  executing->cpu_time_budget = normal_cpu_time_budget ;
+  executing->budget_algorithm = normal_budget_algorithm ;
+  prev_is_preemptible = executing->is_preemptible;
+  executing->is_preemptible = normal_is_preemptible;
+
+  /*
+   * We do the best to avoid recursion in the ASR processing.  A well behaved
+   * application will disable ASR processing during ASR processing.  In this
+   * case, ASR processing is currently disabled.  We do now the thread dispatch
+   * necessary due to a re-enabled preemption mode.  This helps to avoid doing
+   * the next round of ASR processing recursively in _Thread_Dispatch_direct().
+   */
+  if ( normal_is_preemptible && !prev_is_preemptible ) {
+Per_CPU_Control *cpu_self;
+
+cpu_self = _Thread_Dispatch_disable_critical( lock_context );
+_Scheduler_Schedule( executing );
+_Thread_State_release( executing, lock_context );
+_Thread_Dispatch_direct( cpu_self );
+_Thread_State_acquire( executing, lock_context );
+  }
+
+  /*
+   * Restore the normal ASR processing mode.  If we enable ASR processing and
+   * there are pending signals, then add us as a post-switch action.  The loop
+   * in _Thread_Run_post_switch_actions() will continue after our return and
+   * call us again.  This avoids a recursion.
+   */
+
+  prev_asr_is_enabled = asr->is_enabled;
+  asr->is_enabled = normal_asr_is_enabled;
+
+  if (
+normal_asr_is_enabled &&
+  !prev_asr_is_enabled &&
+  asr->signals_pending != 0
+  ) {
+_Thread_Append_post_switch_action( executing, action );
+  }
 }
 
 rtems_status_code rtems_signal_send(
-- 
2.26.2

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

[PATCH 10/13] rtems: Simplify signal handling

[Sebastian Huber]

Remove superfluous ASR_Information::signals_posted.  Move code out of
trivial inline functions.

Update #4244.
---
 cpukit/headers.am   |  1 -
 cpukit/include/rtems/rtems/asrdata.h|  2 -
 cpukit/include/rtems/rtems/asrimpl.h| 90 -
 cpukit/include/rtems/rtems/signalimpl.h | 10 ---
 cpukit/rtems/src/signalcatch.c  | 18 +++--
 cpukit/rtems/src/signalsend.c   | 23 +++
 cpukit/rtems/src/taskmode.c | 24 +++
 spec/build/cpukit/librtemscpu.yml   |  1 -
 8 files changed, 33 insertions(+), 136 deletions(-)
 delete mode 100644 cpukit/include/rtems/rtems/asrimpl.h

diff --git a/cpukit/headers.am b/cpukit/headers.am
index cf7b715115..169126b61a 100644
--- a/cpukit/headers.am
+++ b/cpukit/headers.am
@@ -250,7 +250,6 @@ include_rtems_rfs_HEADERS += 
include/rtems/rfs/rtems-rfs-mutex.h
 include_rtems_rfs_HEADERS += include/rtems/rfs/rtems-rfs-trace.h
 include_rtems_rtems_HEADERS += include/rtems/rtems/asr.h
 include_rtems_rtems_HEADERS += include/rtems/rtems/asrdata.h
-include_rtems_rtems_HEADERS += include/rtems/rtems/asrimpl.h
 include_rtems_rtems_HEADERS += include/rtems/rtems/attr.h
 include_rtems_rtems_HEADERS += include/rtems/rtems/attrimpl.h
 include_rtems_rtems_HEADERS += include/rtems/rtems/barrier.h
diff --git a/cpukit/include/rtems/rtems/asrdata.h 
b/cpukit/include/rtems/rtems/asrdata.h
index b0cb8f3bbc..3f44d3b030 100644
--- a/cpukit/include/rtems/rtems/asrdata.h
+++ b/cpukit/include/rtems/rtems/asrdata.h
@@ -42,8 +42,6 @@ typedef struct {
   rtems_asr_entry   handler;
   /** This field indicates if the task mode the signal will run with. */
   rtems_modemode_set;
-  /** This field indicates the signal set that is posted. */
-  rtems_signal_set  signals_posted;
   /** This field indicates the signal set that is pending. */
   rtems_signal_set  signals_pending;
 }   ASR_Information;
diff --git a/cpukit/include/rtems/rtems/asrimpl.h 
b/cpukit/include/rtems/rtems/asrimpl.h
deleted file mode 100644
index e9369079e6..00
--- a/cpukit/include/rtems/rtems/asrimpl.h
+++ /dev/null
@@ -1,90 +0,0 @@
-/**
- * @file
- *
- * @ingroup RTEMSImplClassicASR
- *
- * @brief This header file provides the implementation interfaces of
- *   the @ref RTEMSImplClassicASR support.
- */
-
-/* COPYRIGHT (c) 1989-2008.
- * On-Line Applications Research Corporation (OAR).
- *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
- */
-
-#ifndef _RTEMS_RTEMS_ASRIMPL_H
-#define _RTEMS_RTEMS_ASRIMPL_H
-
-#include 
-
-#include 
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-/**
- * @defgroup RTEMSImplClassicASR Asynchronous Signal Routine (ASR)
- *
- * @ingroup RTEMSImplClassic
- *
- * @brief This group contains the implementation to support asynchronous signal
- *   routines.
- *
- * @{
- */
-
-/**
- *  @brief ASR_Initialize
- *
- *  This routine initializes the given RTEMS_ASR information record.
- */
-RTEMS_INLINE_ROUTINE void _ASR_Initialize (
-  ASR_Information *asr
-)
-{
-  memset(asr, 0, sizeof(*asr));
-}
-
-RTEMS_INLINE_ROUTINE rtems_signal_set _ASR_Swap_signals( ASR_Information *asr )
-{
-  rtems_signal_set new_signals_posted;
-
-  new_signals_posted   = asr->signals_pending;
-  asr->signals_pending = asr->signals_posted;
-  asr->signals_posted  = new_signals_posted;
-
-  return new_signals_posted;
-}
-
-RTEMS_INLINE_ROUTINE void _ASR_Post_signals(
-  rtems_signal_set  signals,
-  rtems_signal_set *signal_set
-)
-{
-  *signal_set |= signals;
-}
-
-RTEMS_INLINE_ROUTINE rtems_signal_set _ASR_Get_posted_signals(
-  ASR_Information *asr
-)
-{
-  rtems_signal_set signal_set;
-
-  signal_set = asr->signals_posted;
-  asr->signals_posted = 0;
-
-  return signal_set;
-}
-
-/**@}*/
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif
-/* end of include file */
diff --git a/cpukit/include/rtems/rtems/signalimpl.h 
b/cpukit/include/rtems/rtems/signalimpl.h
index 51f742c9fe..db1ff71620 100644
--- a/cpukit/include/rtems/rtems/signalimpl.h
+++ b/cpukit/include/rtems/rtems/signalimpl.h
@@ -31,18 +31,8 @@ extern "C" {
  * @ingroup RTEMSImplClassic
  *
  * @brief This group contains the Signal Manager implementation.
- *
- * @{
  */
 
-void _Signal_Action_handler(
-  Thread_Control   *executing,
-  Thread_Action*action,
-  ISR_lock_Context *lock_context
-);
-
-/**@}*/
-
 #ifdef __cplusplus
 }
 #endif
diff --git a/cpukit/rtems/src/signalcatch.c b/cpukit/rtems/src/signalcatch.c
index e4ff15fd40..8ee22e5ec1 100644
--- a/cpukit/rtems/src/signalcatch.c
+++ b/cpukit/rtems/src/signalcatch.c
@@ -22,7 +22,6 @@
 #endif
 
 #include 
-#include 
 #include 
 #include 
 
@@ -41,12 +40,19 @@ rtems_status_code rtems_signal_catch(
   executing = _Thread_State_acquire_for_executing( &lock_context );
   api = executing->API_Extensions[ THREAD_API_RTEMS ];
   asr = &api->Signal;
+  asr->handler = asr_handler;
+  asr->mode_set = mode_set;
 
-  if ( asr_handler != NULL ) 

[PATCH 05/13] posix: Remove superfluous check

[Sebastian Huber]

The api pointer is never NULL.

Update #4244.
---
 cpukit/posix/src/psignalunblockthread.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/cpukit/posix/src/psignalunblockthread.c 
b/cpukit/posix/src/psignalunblockthread.c
index 63ed823ab3..a1af20a5af 100644
--- a/cpukit/posix/src/psignalunblockthread.c
+++ b/cpukit/posix/src/psignalunblockthread.c
@@ -111,12 +111,6 @@ static void _POSIX_signals_Action_handler(
*/
   hold_errno = executing->Wait.return_code;
 
-  /*
-   * api may be NULL in case of a thread close in progress
-   */
-  if ( !api )
-return;
-
   /*
*  In case the executing thread is blocked or about to block on something
*  that uses the thread wait information, then this is a kernel bug.
-- 
2.26.2

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

[PATCH 04/13] score: Add _Thread_Append_post_switch_action()

[Sebastian Huber]

Update #4244.
---
 cpukit/include/rtems/score/threadimpl.h | 38 ++---
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/cpukit/include/rtems/score/threadimpl.h 
b/cpukit/include/rtems/score/threadimpl.h
index e76f9c3972..e9d44526da 100644
--- a/cpukit/include/rtems/score/threadimpl.h
+++ b/cpukit/include/rtems/score/threadimpl.h
@@ -1236,11 +1236,16 @@ RTEMS_INLINE_ROUTINE void _Thread_Action_initialize(
 }
 
 /**
- * @brief Adds a post switch action to the thread with the given handler.
+ * @brief Adds the post switch action to the thread.
  *
- * @param[in, out] the_thread The thread.
- * @param[in,  out] action The action to add.
- * @param handler The handler for the action.
+ * The caller shall own the thread state lock.  A thread dispatch is
+ * requested.
+ *
+ * @param[in, out] the_thread is the thread of the action.
+ *
+ * @param[in, out] action is the action to add.
+ *
+ * @param handler is the handler for the action.
  */
 RTEMS_INLINE_ROUTINE void _Thread_Add_post_switch_action(
   Thread_Control*the_thread,
@@ -1264,6 +1269,31 @@ RTEMS_INLINE_ROUTINE void _Thread_Add_post_switch_action(
   );
 }
 
+/**
+ * @brief Appends the post switch action to the thread.
+ *
+ * The caller shall own the thread state lock.  The action shall be inactive.
+ * The handler of the action shall be already set.  A thread dispatch is not
+ * requested.
+ *
+ * @param[in, out] the_thread is the thread of the action.
+ *
+ * @param[in, out] action is the action to add.
+ */
+RTEMS_INLINE_ROUTINE void _Thread_Append_post_switch_action(
+  Thread_Control *the_thread,
+  Thread_Action  *action
+)
+{
+  _Assert( _Thread_State_is_owner( the_thread ) );
+  _Assert( action->handler != NULL );
+
+  _Chain_Append_unprotected(
+&the_thread->Post_switch_actions.Chain,
+&action->Node
+  );
+}
+
 /**
  * @brief Checks if the thread life state is restarting.
  *
-- 
2.26.2

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

[PATCH 01/13] validation: Add Validation1 test suite

[Sebastian Huber]

Update #4244.
---
 spec/build/bsps/tstsmallmem.yml   |  1 +
 spec/build/testsuites/validation/grp.yml  |  2 +
 .../testsuites/validation/validation-1.yml| 19 +
 testsuites/validation/ts-default.h|  4 +-
 testsuites/validation/ts-validation-0.c   |  4 +-
 testsuites/validation/ts-validation-1.c   | 75 +++
 6 files changed, 100 insertions(+), 5 deletions(-)
 create mode 100644 spec/build/testsuites/validation/validation-1.yml
 create mode 100644 testsuites/validation/ts-validation-1.c

diff --git a/spec/build/bsps/tstsmallmem.yml b/spec/build/bsps/tstsmallmem.yml
index 559d44362b..3d1ffa6b57 100644
--- a/spec/build/bsps/tstsmallmem.yml
+++ b/spec/build/bsps/tstsmallmem.yml
@@ -11,6 +11,7 @@ actions:
 sp47: exclude
 spstkalloc02: exclude
 validation-0: exclude
+validation-1: exclude
 - set-value: -DPER_ALLOCATION=10
 - append-test-cppflags: sp71
 - set-value: -DMAXIMUM_DISTRIBUTION=10
diff --git a/spec/build/testsuites/validation/grp.yml 
b/spec/build/testsuites/validation/grp.yml
index 1a903a4198..564b1c62ac 100644
--- a/spec/build/testsuites/validation/grp.yml
+++ b/spec/build/testsuites/validation/grp.yml
@@ -14,6 +14,8 @@ links:
   uid: performance-0
 - role: build-dependency
   uid: validation-0
+- role: build-dependency
+  uid: validation-1
 type: build
 use-after:
 - rtemstest
diff --git a/spec/build/testsuites/validation/validation-1.yml 
b/spec/build/testsuites/validation/validation-1.yml
new file mode 100644
index 00..4972e45034
--- /dev/null
+++ b/spec/build/testsuites/validation/validation-1.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/validation/ts-validation-1.c
+stlib: []
+target: testsuites/validation/ts-validation-1.exe
+type: build
+use-after: []
+use-before: []
diff --git a/testsuites/validation/ts-default.h 
b/testsuites/validation/ts-default.h
index 0385587beb..e8e2334825 100644
--- a/testsuites/validation/ts-default.h
+++ b/testsuites/validation/ts-default.h
@@ -133,8 +133,6 @@ static void task_stack_deallocate( void *stack )
 
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 
-#define CONFIGURE_MAXIMUM_PROCESSORS 4
-
 #define CONFIGURE_MAXIMUM_BARRIERS 3
 
 #define CONFIGURE_MAXIMUM_MESSAGE_QUEUES 3
@@ -178,7 +176,7 @@ static void task_stack_deallocate( void *stack )
 
 #define CONFIGURE_INIT_TASK_CONSTRUCT_STORAGE_SIZE TASK_STORAGE_SIZE
 
-#if defined(RTEMS_SMP)
+#if defined(RTEMS_SMP) && CONFIGURE_MAXIMUM_PROCESSORS == 4
 
 #define CONFIGURE_SCHEDULER_EDF_SMP
 
diff --git a/testsuites/validation/ts-validation-0.c 
b/testsuites/validation/ts-validation-0.c
index c56bd5ea81..4e0459edf8 100644
--- a/testsuites/validation/ts-validation-0.c
+++ b/testsuites/validation/ts-validation-0.c
@@ -52,8 +52,6 @@
 #include "config.h"
 #endif
 
-#include 
-
 #include 
 
 /**
@@ -72,6 +70,8 @@
 
 const char rtems_test_name[] = "Validation0";
 
+#define CONFIGURE_MAXIMUM_PROCESSORS 4
+
 #include "ts-default.h"
 
 /** @} */
diff --git a/testsuites/validation/ts-validation-1.c 
b/testsuites/validation/ts-validation-1.c
new file mode 100644
index 00..11bef51fb7
--- /dev/null
+++ b/testsuites/validation/ts-validation-1.c
@@ -0,0 +1,75 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestSuiteTestsuitesValidation1
+ */
+
+/*
+ * Copyright (C) 2021 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

[PATCH 08/13] rtems: Remove unused ASR_Information::nest_level

[Sebastian Huber]

Update #4244.
---
 cpukit/include/rtems/rtems/asrdata.h | 2 --
 cpukit/rtems/src/signalcatch.c   | 2 --
 2 files changed, 4 deletions(-)

diff --git a/cpukit/include/rtems/rtems/asrdata.h 
b/cpukit/include/rtems/rtems/asrdata.h
index caf29a0863..b0cb8f3bbc 100644
--- a/cpukit/include/rtems/rtems/asrdata.h
+++ b/cpukit/include/rtems/rtems/asrdata.h
@@ -46,8 +46,6 @@ typedef struct {
   rtems_signal_set  signals_posted;
   /** This field indicates the signal set that is pending. */
   rtems_signal_set  signals_pending;
-  /** This field indicates if nest level of signals being processed */
-  uint32_t  nest_level;
 }   ASR_Information;
 
 /** @} */
diff --git a/cpukit/rtems/src/signalcatch.c b/cpukit/rtems/src/signalcatch.c
index 2fd7c13374..27d7503a31 100644
--- a/cpukit/rtems/src/signalcatch.c
+++ b/cpukit/rtems/src/signalcatch.c
@@ -57,12 +57,10 @@ void _Signal_Action_handler(
 
   _Thread_State_release( executing, lock_context );
 
-  asr->nest_level += 1;
   rtems_task_mode( asr->mode_set, RTEMS_ALL_MODE_MASKS, &prev_mode );
 
   (*asr->handler)( signal_set );
 
-  asr->nest_level -= 1;
   rtems_task_mode( prev_mode, RTEMS_ALL_MODE_MASKS, &prev_mode );
 
   _Thread_State_acquire( executing, lock_context );
-- 
2.26.2

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

[PATCH 02/13] validation: Add signal manager tests

[Sebastian Huber]

Update #4244.
---
 .../testsuites/validation/validation-0.yml|2 +
 .../testsuites/validation/validation-1.yml|2 +
 testsuites/validation/tc-signal-catch.c   | 1017 +++
 testsuites/validation/tc-signal-send.c| 1146 +
 4 files changed, 2167 insertions(+)
 create mode 100644 testsuites/validation/tc-signal-catch.c
 create mode 100644 testsuites/validation/tc-signal-send.c

diff --git a/spec/build/testsuites/validation/validation-0.yml 
b/spec/build/testsuites/validation/validation-0.yml
index 70448cb091..02e5744145 100644
--- a/spec/build/testsuites/validation/validation-0.yml
+++ b/spec/build/testsuites/validation/validation-0.yml
@@ -17,6 +17,8 @@ source:
 - testsuites/validation/tc-barrier-wait.c
 - testsuites/validation/tc-message-construct-errors.c
 - testsuites/validation/tc-object.c
+- testsuites/validation/tc-signal-catch.c
+- testsuites/validation/tc-signal-send.c
 - testsuites/validation/tc-task-construct-errors.c
 - testsuites/validation/ts-validation-0.c
 stlib: []
diff --git a/spec/build/testsuites/validation/validation-1.yml 
b/spec/build/testsuites/validation/validation-1.yml
index 4972e45034..fa61c96c2f 100644
--- a/spec/build/testsuites/validation/validation-1.yml
+++ b/spec/build/testsuites/validation/validation-1.yml
@@ -11,6 +11,8 @@ includes: []
 ldflags: []
 links: []
 source:
+- testsuites/validation/tc-signal-catch.c
+- testsuites/validation/tc-signal-send.c
 - testsuites/validation/ts-validation-1.c
 stlib: []
 target: testsuites/validation/ts-validation-1.exe
diff --git a/testsuites/validation/tc-signal-catch.c 
b/testsuites/validation/tc-signal-catch.c
new file mode 100644
index 00..9c14cc93a3
--- /dev/null
+++ b/testsuites/validation/tc-signal-catch.c
@@ -0,0 +1,1017 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestCaseRtemsSignalReqCatch
+ */
+
+/*
+ * Copyright (C) 2021 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 is part of the RTEMS quality process and was automatically
+ * generated.  If you find something that needs to be fixed or
+ * worded better please post a report or patch to an RTEMS mailing list
+ * or raise a bug report:
+ *
+ * https://www.rtems.org/bugs.html
+ *
+ * For information on updating and regenerating please refer to the How-To
+ * section in the Software Requirements Engineering chapter of the
+ * RTEMS Software Engineering manual.  The manual is provided as a part of
+ * a release.  For development sources please refer to the online
+ * documentation at:
+ *
+ * https://docs.rtems.org
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#include 
+
+/**
+ * @defgroup RTEMSTestCaseRtemsSignalReqCatch spec:/rtems/signal/req/catch
+ *
+ * @ingroup RTEMSTestSuiteTestsuitesValidation0
+ * @ingroup RTEMSTestSuiteTestsuitesValidation1
+ *
+ * @{
+ */
+
+typedef enum {
+  RtemsSignalReqCatch_Pre_Handler_Invalid,
+  RtemsSignalReqCatch_Pre_Handler_Valid,
+  RtemsSignalReqCatch_Pre_Handler_NA
+} RtemsSignalReqCatch_Pre_Handler;
+
+typedef enum {
+  RtemsSignalReqCatch_Pre_Preempt_Yes,
+  RtemsSignalReqCatch_Pre_Preempt_No,
+  RtemsSignalReqCatch_Pre_Preempt_NA
+} RtemsSignalReqCatch_Pre_Preempt;
+
+typedef enum {
+  RtemsSignalReqCatch_Pre_Timeslice_Yes,
+  RtemsSignalReqCatch_Pre_Timeslice_No,
+  RtemsSignalReqCatch_Pre_Timeslice_NA
+} RtemsSignalReqCatch_Pre_Timeslice;
+
+typedef enum {
+  RtemsSignalReqCatch_Pre_ASR_Yes,
+  RtemsSignalReqCatch_Pre_ASR_No,
+  RtemsSignalReqCatch_Pre_ASR_NA
+} RtemsSignalReqCatch_Pre_ASR;
+
+typedef enum {
+  RtemsSignalReqCatch_Pre_IntLvl_Zero,
+  RtemsSignalReqCatch_Pre_In

[PATCH 11/13] rtems: New errors for rtems_signal_catch()

[Sebastian Huber]

Ensure that no invalid modes are set during ASR processing.

Update #4244.
---
 cpukit/rtems/src/signalcatch.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/cpukit/rtems/src/signalcatch.c b/cpukit/rtems/src/signalcatch.c
index 8ee22e5ec1..da56d26dc5 100644
--- a/cpukit/rtems/src/signalcatch.c
+++ b/cpukit/rtems/src/signalcatch.c
@@ -22,7 +22,10 @@
 #endif
 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
 
 RTEMS_STATIC_ASSERT( RTEMS_DEFAULT_MODES == 0, _ASR_Create_mode_set );
@@ -37,7 +40,31 @@ rtems_status_code rtems_signal_catch(
   ASR_Information*asr;
   ISR_lock_Contextlock_context;
 
+#if defined(RTEMS_SMP) || CPU_ENABLE_ROBUST_THREAD_DISPATCH == TRUE
+  if (
+_Modes_Get_interrupt_level( mode_set ) != 0
+#if CPU_ENABLE_ROBUST_THREAD_DISPATCH == FALSE
+  && _SMP_Need_inter_processor_interrupts()
+#endif
+  ) {
+return RTEMS_NOT_IMPLEMENTED;
+  }
+#endif
+
   executing = _Thread_State_acquire_for_executing( &lock_context );
+
+#if defined(RTEMS_SMP)
+  if (
+!_Modes_Is_preempt( mode_set ) &&
+  !_Scheduler_Is_non_preempt_mode_supported(
+_Thread_Scheduler_get_home( executing )
+  )
+  ) {
+_Thread_State_release( executing, &lock_context );
+return RTEMS_NOT_IMPLEMENTED;
+  }
+#endif
+
   api = executing->API_Extensions[ THREAD_API_RTEMS ];
   asr = &api->Signal;
   asr->handler = asr_handler;
-- 
2.26.2

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

[PATCH 07/13] rtems: Remove unused _Modes_Change()

[Sebastian Huber]

Update #4244.
---
 cpukit/include/rtems/rtems/modesimpl.h | 26 --
 1 file changed, 26 deletions(-)

diff --git a/cpukit/include/rtems/rtems/modesimpl.h 
b/cpukit/include/rtems/rtems/modesimpl.h
index db98cb419f..5677c7f13d 100644
--- a/cpukit/include/rtems/rtems/modesimpl.h
+++ b/cpukit/include/rtems/rtems/modesimpl.h
@@ -99,32 +99,6 @@ RTEMS_INLINE_ROUTINE void _Modes_Set_interrupt_level (
   _ISR_Set_level( _Modes_Get_interrupt_level( mode_set ) );
 }
 
-/**
- *  @brief Changes the modes in old_mode_set indicated by
- *  mask to the requested values in new_mode_set.
- *
- *  This routine changes the modes in old_mode_set indicated by
- *  mask to the requested values in new_mode_set.  The resulting
- *  mode set is returned in out_mode_set and the modes that changed
- *  is returned in changed.
- */
-RTEMS_INLINE_ROUTINE void _Modes_Change (
-  rtems_mode  old_mode_set,
-  rtems_mode  new_mode_set,
-  rtems_mode  mask,
-  rtems_mode *out_mode_set,
-  rtems_mode *changed
-)
-{
-  rtems_mode _out_mode;
-
-  _out_mode  =  old_mode_set;
-  _out_mode &= ~mask;
-  _out_mode |= new_mode_set & mask;
-  *changed   = _out_mode ^ old_mode_set;
-  *out_mode_set  = _out_mode;
-}
-
 #ifdef __cplusplus
 }
 #endif
-- 
2.26.2

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

[PATCH 06/13] rtems: Remove unused _Modes_Mask_changed()

[Sebastian Huber]

Update #4244.
---
 cpukit/include/rtems/rtems/modesimpl.h | 14 --
 1 file changed, 14 deletions(-)

diff --git a/cpukit/include/rtems/rtems/modesimpl.h 
b/cpukit/include/rtems/rtems/modesimpl.h
index 5a147b10b9..db98cb419f 100644
--- a/cpukit/include/rtems/rtems/modesimpl.h
+++ b/cpukit/include/rtems/rtems/modesimpl.h
@@ -35,20 +35,6 @@ extern "C" {
  * @{
  */
 
-/**
- *  @brief Checks if any of the mode flags in mask are set in mode_set.
- *
- *  This function returns TRUE if any of the mode flags in mask
- *  are set in mode_set, and FALSE otherwise.
- */
-RTEMS_INLINE_ROUTINE bool _Modes_Mask_changed (
-  rtems_mode mode_set,
-  rtems_mode masks
-)
-{
-   return ( mode_set & masks ) ? true : false;
-}
-
 /**
  *  @brief Checks if mode_set says that Asynchronous Signal Processing is 
disabled.
  *
-- 
2.26.2

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

[PATCH 09/13] rtems: Move _Signal_Action_handler()

[Sebastian Huber]

Move _Signal_Action_handler() and signal MP initialization to
rtems_signal_send().  The goal is to make _Signal_Action_handler() a
static function in a follow up patch.

Update #4244.
---
 cpukit/rtems/src/signalcatch.c | 54 --
 cpukit/rtems/src/signalsend.c  | 54 ++
 2 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/cpukit/rtems/src/signalcatch.c b/cpukit/rtems/src/signalcatch.c
index 27d7503a31..e4ff15fd40 100644
--- a/cpukit/rtems/src/signalcatch.c
+++ b/cpukit/rtems/src/signalcatch.c
@@ -21,51 +21,13 @@
 #include "config.h"
 #endif
 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 RTEMS_STATIC_ASSERT( RTEMS_DEFAULT_MODES == 0, _ASR_Create_mode_set );
 
-void _Signal_Action_handler(
-  Thread_Control   *executing,
-  Thread_Action*action,
-  ISR_lock_Context *lock_context
-)
-{
-  RTEMS_API_Control *api;
-  ASR_Information   *asr;
-  rtems_signal_set   signal_set;
-  rtems_mode  prev_mode;
-
-  (void) action;
-
-  /*
-   *  Signal Processing
-   */
-
-  api = executing->API_Extensions[ THREAD_API_RTEMS ];
-  asr = &api->Signal;
-  signal_set = _ASR_Get_posted_signals( asr );
-
-  if ( signal_set == 0 ) {
-return;
-  }
-
-  _Thread_State_release( executing, lock_context );
-
-  rtems_task_mode( asr->mode_set, RTEMS_ALL_MODE_MASKS, &prev_mode );
-
-  (*asr->handler)( signal_set );
-
-  rtems_task_mode( prev_mode, RTEMS_ALL_MODE_MASKS, &prev_mode );
-
-  _Thread_State_acquire( executing, lock_context );
-}
-
 rtems_status_code rtems_signal_catch(
   rtems_asr_entry   asr_handler,
   rtems_modemode_set
@@ -90,19 +52,3 @@ rtems_status_code rtems_signal_catch(
   _Thread_State_release( executing, &lock_context );
   return RTEMS_SUCCESSFUL;
 }
-
-#if defined(RTEMS_MULTIPROCESSING)
-static void _Signal_MP_Initialize( void )
-{
-  _MPCI_Register_packet_processor(
-MP_PACKET_SIGNAL,
-_Signal_MP_Process_packet
-  );
-}
-
-RTEMS_SYSINIT_ITEM(
-  _Signal_MP_Initialize,
-  RTEMS_SYSINIT_CLASSIC_SIGNAL_MP,
-  RTEMS_SYSINIT_ORDER_MIDDLE
-);
-#endif
diff --git a/cpukit/rtems/src/signalsend.c b/cpukit/rtems/src/signalsend.c
index efc3a9566a..fc8a66b6c6 100644
--- a/cpukit/rtems/src/signalsend.c
+++ b/cpukit/rtems/src/signalsend.c
@@ -26,6 +26,44 @@
 #include 
 #include 
 
+#include 
+
+void _Signal_Action_handler(
+  Thread_Control   *executing,
+  Thread_Action*action,
+  ISR_lock_Context *lock_context
+)
+{
+  RTEMS_API_Control *api;
+  ASR_Information   *asr;
+  rtems_signal_set   signal_set;
+  rtems_mode  prev_mode;
+
+  (void) action;
+
+  /*
+   *  Signal Processing
+   */
+
+  api = executing->API_Extensions[ THREAD_API_RTEMS ];
+  asr = &api->Signal;
+  signal_set = _ASR_Get_posted_signals( asr );
+
+  if ( signal_set == 0 ) {
+return;
+  }
+
+  _Thread_State_release( executing, lock_context );
+
+  rtems_task_mode( asr->mode_set, RTEMS_ALL_MODE_MASKS, &prev_mode );
+
+  (*asr->handler)( signal_set );
+
+  rtems_task_mode( prev_mode, RTEMS_ALL_MODE_MASKS, &prev_mode );
+
+  _Thread_State_acquire( executing, lock_context );
+}
+
 rtems_status_code rtems_signal_send(
   rtems_id  id,
   rtems_signal_set  signal_set
@@ -79,3 +117,19 @@ rtems_status_code rtems_signal_send(
 
   return RTEMS_SUCCESSFUL;
 }
+
+#if defined(RTEMS_MULTIPROCESSING)
+static void _Signal_MP_Initialize( void )
+{
+  _MPCI_Register_packet_processor(
+MP_PACKET_SIGNAL,
+_Signal_MP_Process_packet
+  );
+}
+
+RTEMS_SYSINIT_ITEM(
+  _Signal_MP_Initialize,
+  RTEMS_SYSINIT_CLASSIC_SIGNAL_MP,
+  RTEMS_SYSINIT_ORDER_MIDDLE
+);
+#endif
-- 
2.26.2

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

RE: splinkersets01 test assumptions

[Kinsey Moore]

Thanks for taking a look at this. I'll push this up to GCC. In the meantime, 
I'll remove SUBALIGN and adjust things as necessary.

Kinsey

-Original Message-
From: Sebastian Huber  
Sent: Wednesday, February 17, 2021 11:20
To: Kinsey Moore ; devel@rtems.org
Subject: Re: splinkersets01 test assumptions

On 17/02/2021 17:41, Kinsey Moore wrote:

 I would remove the SUBALIGN() from the linker script. You can also add a
 new test case for splinkersets01 similar to struct s from above. Then we
 should check if the test fails on aarch64 and why it fails.
>>> The example above actually shows the issue I'm having in 
>>> _Linker_set_i_begin and _Linker_set_i_end. The alignment expands for the 
>>> larger struct, but does not shrink for data types smaller than 8 bytes, 
>>> leaving padding that the test interprets as additional space in the linker 
>>> set.
>> I still don't see why a larger alignment is an issue. The begin/end
>> objects have a size of zero. Where do you observe a padding?
> Even when the begin/end objects have a size of 0, they're aligned out to 8 
> bytes forcing empty bytes if the content does not exactly fill a multiple of 
> 8 bytes. Those non-content bytes are counted as part of the section.

Ok, it took a while, but I understand now the problem. I think this is a 
GCC bug.

cat test-align.c
char i;
char j[1];
char z[0];
unsigned long ai = _Alignof(i);
unsigned long aj = _Alignof(j);
unsigned long az = _Alignof(z);

aarch64-rtems6-gcc -O2 -S -o - test-align.c -mabi=ilp32 -fdata-sections
     .arch armv8-a
     .file   "test-align.c"
     .text
     .global az
     .global aj
     .global ai
     .global z
     .global j
     .global i
     .section    .bss.i,"aw",@nobits
     .type   i, %object
     .size   i, 1
i:
     .zero   1
     .section    .bss.j,"aw",@nobits
     .align  3
     .type   j, %object
     .size   j, 1
j:
     .zero   1
     .section    .bss.z,"aw",@nobits
     .align  3
     .type   z, %object
     .size   z, 0
z:
     .section    .data.ai,"aw"
     .align  2
     .type   ai, %object
     .size   ai, 4
ai:
     .word   1
     .section    .data.aj,"aw"
     .align  2
     .type   aj, %object
     .size   aj, 4
aj:
     .word   1
     .section    .data.az,"aw"
     .align  2
     .type   az, %object
     .size   az, 4
az:
     .word   1
     .ident  "GCC: (GNU) 10.2.1 20210205 (RTEMS 6, RSB 
61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f)"

clang --target=aarch64 -O2 -S -o - test-align.c  -fdata-sections -fno-common
test-align.c:4:20: warning: '_Alignof' applied to an expression is a GNU 
extension [-Wgnu-alignof-expression]
unsigned long ai = _Alignof(i);
    ^
test-align.c:5:20: warning: '_Alignof' applied to an expression is a GNU 
extension [-Wgnu-alignof-expression]
unsigned long aj = _Alignof(j);
    ^
test-align.c:6:20: warning: '_Alignof' applied to an expression is a GNU 
extension [-Wgnu-alignof-expression]
unsigned long az = _Alignof(z);
    ^
     .text
     .file   "test-align.c"
     .type   ai,@object  // @ai
     .section    .data.ai,"aw",@progbits
     .globl  ai
     .p2align    3
ai:
     .xword  1   // 0x1
     .size   ai, 8

     .type   aj,@object  // @aj
     .section    .data.aj,"aw",@progbits
     .globl  aj
     .p2align    3
aj:
     .xword  1   // 0x1
     .size   aj, 8

     .type   az,@object  // @az
     .section    .data.az,"aw",@progbits
     .globl  az
     .p2align    3
az:
     .xword  1   // 0x1
     .size   az, 8

     .type   i,@object   // @i
     .section    .bss.i,"aw",@nobits
     .globl  i
i:
     .byte   0   // 0x0
     .size   i, 1

     .type   j,@object   // @j
     .section    .bss.j,"aw",@nobits
     .globl  j
j:
     .zero   1
     .size   j, 1

     .type   z,@object   // @z
     .section    .bss.z,"aw",@nobits
     .globl  z
z:
     .size   z, 0


     .ident  "clang version 9.0.1 "
     .section    ".note.GNU-stack","",@progbits
     .addrsig
3 warnings generated.

I would file a GCC bug report.

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

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

_

Fwd: Buildbot failure in RTEMS on powerpc/psim FreeBSD 10.1-STABLE GCC 7.3.0 POSIX

[Joel Sherrill]

Any idea why psim fails on buildbot but not the other BSPs run through
buildbot?

Did Amar miss updating the powerpc tools?

-- Forwarded message -
From: 
Date: Wed, Feb 17, 2021 at 2:02 PM
Subject: Buildbot failure in RTEMS on powerpc/psim FreeBSD 10.1-STABLE GCC
7.3.0 POSIX
To: 


The Buildbot has detected a failed build on builder powerpc/psim FreeBSD
10.1-STABLE GCC 7.3.0 POSIX while building rtems.
Full details are available at:
https://buildbot.rtems.org/#builders/19/builds/429

Buildbot URL: https://buildbot.rtems.org/

Worker for this Build: build-1

Build Reason: 
Blamelist: Chris Johns , G S Niteesh Babu <
niteesh...@gmail.com>, Ryan Long , Sebastian Huber <
sebastian.hu...@embedded-brains.de>

BUILD FAILED: failed make (failure)

Sincerely,
 -The Buildbot

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

Re: [PATCH 1/1] zynq-uart: Fix set_attributes implementation

[Chris Johns]

On 17/2/21 11:47 pm, jan.som...@dlr.de wrote:
>> -Original Message-
>> From: Chris Johns 
>> Sent: Wednesday, February 10, 2021 12:08 AM
>> To: Sommer, Jan ; devel@rtems.org
>> Subject: Re: [PATCH 1/1] zynq-uart: Fix set_attributes implementation
>>
>> On 9/2/21 11:42 pm, Jan Sommer wrote:
>>> From: Kinsey Moore 
>>>
>>> The zynq-uart set_attributes implementation was configured to always
>>> return false which causes spconsole01 to fail. This restores the
>>> disabled implementation which sets the baud rate registers
>>> appropriately and allows spconsole01 to pass. This also expands the
>>> set_attributes functionality to allow setting of the stop bits,
>>> character width, and parity.
>>
>> Hmmm I missed this change.
>>
>> Sebastian changed the Zynq driver to return an error. Returning an error is
>> correct because the attributes are not being set however we have a couple
>> of design approaches clashing.
>>
>> The issue pulls right back to the Xilinx SystemZ design dialogue box. The
>> hardware designer has the ability to set the serial port defaults. These
>> settings form part of the ps7init data the FSBL paints into the hardware very
>> early in the boot process. Also in this data are parallel port pin settings, 
>> AXI
>> clocks, memory and more so lots of important stuff. The Xilinx bootloader
>> and ones I have created (I do not know about uboot) do not touch the UART
>> hardware on purpose so the system designer has control. Then in 2017
>> Sebastian pushed a change to force the baudrate to a BSP specific default.
>>
>> This is normally all OK because all Zynq designs I know of use the default of
>> 115200,8,n,1 for the configuration. A problem arises when these defaults are
>> varied.
>>
>> Maybe something explaining this in the user manual ...
>>
>> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#xilinx-
>> zynq
>>
>> so we have provided information on what to change?
>>
> 
> Do I understand it correctly, that a patch adding something like the 
> following would be sufficient?

Sort of. The baudrate is now hard coded to 115200 so I it is not clear to me the
purpse of this is other than letting a test pass. It appears we know only
support one console set up.

> Console
> ---
> 
> The console driver for the UARTs of the Zynq SoC will be initialized to a 
> baud rate
> of 115200 with 8 bit characters, 1 stop bit and no parity bits.

Initialised or always set to 115200? The rate is hard coded.

> Previous configurations from , e.g., a bootloader will be overwritten.

Previous configurations programmed into the hardware by the Xilinx tools or a
bootloader will be overwritten.

> If a different setting is required, the user application can configure the 
> console device
> through the standard termios API, e.g. in the init task.

All except the baudrate.

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

Re: Fwd: Buildbot failure in RTEMS on powerpc/psim FreeBSD 10.1-STABLE GCC 7.3.0 POSIX

[Chris Johns]

On 18/2/21 7:18 am, Joel Sherrill wrote:
> Any idea why psim fails on buildbot but not the other BSPs run through 
> buildbot?
> 
> Did Amar miss updating the powerpc tools?

Autoconf vs waf? Buildbot is still on autoconf.

Chris

> 
> -- Forwarded message -
> From: mailto:build...@rtems.org>>
> Date: Wed, Feb 17, 2021 at 2:02 PM
> Subject: Buildbot failure in RTEMS on powerpc/psim FreeBSD 10.1-STABLE GCC 
> 7.3.0
> POSIX
> To: mailto:bu...@rtems.org>>
> 
> 
> The Buildbot has detected a failed build on builder powerpc/psim FreeBSD
> 10.1-STABLE GCC 7.3.0 POSIX while building rtems.
> Full details are available at:
>     https://buildbot.rtems.org/#builders/19/builds/429
> 
> 
> Buildbot URL: https://buildbot.rtems.org/ 
> 
> Worker for this Build: build-1
> 
> Build Reason: 
> Blamelist: Chris Johns mailto:chr...@rtems.org>>, G S 
> Niteesh
> Babu mailto:niteesh...@gmail.com>>, Ryan Long
> mailto:ryan.l...@oarcorp.com>>, Sebastian Huber
>  >
> 
> BUILD FAILED: failed make (failure)
> 
> Sincerely,
>  -The Buildbot
> 
> ___
> build mailing list
> bu...@rtems.org 
> http://lists.rtems.org/mailman/listinfo/build
> 
> 
> ___
> 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: Fwd: Buildbot failure in RTEMS on powerpc/psim FreeBSD 10.1-STABLE GCC 7.3.0 POSIX

[Joel Sherrill]

On Wed, Feb 17, 2021, 2:56 PM Chris Johns  wrote:

> On 18/2/21 7:18 am, Joel Sherrill wrote:
> > Any idea why psim fails on buildbot but not the other BSPs run through
> buildbot?
> >
> > Did Amar miss updating the powerpc tools?
>
> Autoconf vs waf? Buildbot is still on autoconf.
>

That's it. PowerPC is broken on master for autoconf. :(





> Chris
>
> >
> > -- Forwarded message -
> > From: mailto:build...@rtems.org>>
> > Date: Wed, Feb 17, 2021 at 2:02 PM
> > Subject: Buildbot failure in RTEMS on powerpc/psim FreeBSD 10.1-STABLE
> GCC 7.3.0
> > POSIX
> > To: mailto:bu...@rtems.org>>
> >
> >
> > The Buildbot has detected a failed build on builder powerpc/psim FreeBSD
> > 10.1-STABLE GCC 7.3.0 POSIX while building rtems.
> > Full details are available at:
> > https://buildbot.rtems.org/#builders/19/builds/429
> > 
> >
> > Buildbot URL: https://buildbot.rtems.org/ 
> >
> > Worker for this Build: build-1
> >
> > Build Reason: 
> > Blamelist: Chris Johns mailto:chr...@rtems.org>>, G
> S Niteesh
> > Babu mailto:niteesh...@gmail.com>>, Ryan Long
> > mailto:ryan.l...@oarcorp.com>>, Sebastian Huber
> >  sebastian.hu...@embedded-brains.de>>
> >
> > BUILD FAILED: failed make (failure)
> >
> > Sincerely,
> >  -The Buildbot
> >
> > ___
> > build mailing list
> > bu...@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/build
> > 
> >
> > ___
> > 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: Fwd: Buildbot failure in RTEMS on powerpc/psim FreeBSD 10.1-STABLE GCC 7.3.0 POSIX

[Gedare Bloom]

On Wed, Feb 17, 2021 at 2:12 PM Joel Sherrill  wrote:
>
>
>
> On Wed, Feb 17, 2021, 2:56 PM Chris Johns  wrote:
>>
>> On 18/2/21 7:18 am, Joel Sherrill wrote:
>> > Any idea why psim fails on buildbot but not the other BSPs run through 
>> > buildbot?
>> >
>> > Did Amar miss updating the powerpc tools?
>>
>> Autoconf vs waf? Buildbot is still on autoconf.
>
>
> That's it. PowerPC is broken on master for autoconf. :(
>
kill it!!

ok, what has to be done to make some people happy with cutting us off
from autotools?

>
>
>
>>
>> Chris
>>
>> >
>> > -- Forwarded message -
>> > From: mailto:build...@rtems.org>>
>> > Date: Wed, Feb 17, 2021 at 2:02 PM
>> > Subject: Buildbot failure in RTEMS on powerpc/psim FreeBSD 10.1-STABLE GCC 
>> > 7.3.0
>> > POSIX
>> > To: mailto:bu...@rtems.org>>
>> >
>> >
>> > The Buildbot has detected a failed build on builder powerpc/psim FreeBSD
>> > 10.1-STABLE GCC 7.3.0 POSIX while building rtems.
>> > Full details are available at:
>> > https://buildbot.rtems.org/#builders/19/builds/429
>> > 
>> >
>> > Buildbot URL: https://buildbot.rtems.org/ 
>> >
>> > Worker for this Build: build-1
>> >
>> > Build Reason: 
>> > Blamelist: Chris Johns mailto:chr...@rtems.org>>, G S 
>> > Niteesh
>> > Babu mailto:niteesh...@gmail.com>>, Ryan Long
>> > mailto:ryan.l...@oarcorp.com>>, Sebastian Huber
>> > > > >
>> >
>> > BUILD FAILED: failed make (failure)
>> >
>> > Sincerely,
>> >  -The Buildbot
>> >
>> > ___
>> > build mailing list
>> > bu...@rtems.org 
>> > http://lists.rtems.org/mailman/listinfo/build
>> > 
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> >
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: Buildbot failure in RTEMS on powerpc/psim FreeBSD 10.1-STABLE GCC 7.3.0 POSIX

[Joel Sherrill]

On Wed, Feb 17, 2021 at 3:36 PM Gedare Bloom  wrote:

> On Wed, Feb 17, 2021 at 2:12 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Wed, Feb 17, 2021, 2:56 PM Chris Johns  wrote:
> >>
> >> On 18/2/21 7:18 am, Joel Sherrill wrote:
> >> > Any idea why psim fails on buildbot but not the other BSPs run
> through buildbot?
> >> >
> >> > Did Amar miss updating the powerpc tools?
> >>
> >> Autoconf vs waf? Buildbot is still on autoconf.
> >
> >
> > That's it. PowerPC is broken on master for autoconf. :(
> >
> kill it!!
>
> ok, what has to be done to make some people happy with cutting us off
> from autotools?
>

As the proud representative of the "some people", there were only two things
on the list until BuildBot added itself.

+ rtems-bsp-builder
+ build bot
+ rtems kernel RSB

Some fine people ordered them that way because the first two are critical
for our automated testing builds. The last one is important and user facing
but it might be a candidate for after removing autoconf. Breaks
RTEMS packaging via RSB

The "some people" were as happy with the state of the BSPs on autoconf
vs waf as is possible.

--joel


>
> >
> >
> >
> >>
> >> Chris
> >>
> >> >
> >> > -- Forwarded message -
> >> > From: mailto:build...@rtems.org>>
> >> > Date: Wed, Feb 17, 2021 at 2:02 PM
> >> > Subject: Buildbot failure in RTEMS on powerpc/psim FreeBSD
> 10.1-STABLE GCC 7.3.0
> >> > POSIX
> >> > To: mailto:bu...@rtems.org>>
> >> >
> >> >
> >> > The Buildbot has detected a failed build on builder powerpc/psim
> FreeBSD
> >> > 10.1-STABLE GCC 7.3.0 POSIX while building rtems.
> >> > Full details are available at:
> >> > https://buildbot.rtems.org/#builders/19/builds/429
> >> > 
> >> >
> >> > Buildbot URL: https://buildbot.rtems.org/ <
> https://buildbot.rtems.org/>
> >> >
> >> > Worker for this Build: build-1
> >> >
> >> > Build Reason: 
> >> > Blamelist: Chris Johns mailto:chr...@rtems.org>>,
> G S Niteesh
> >> > Babu mailto:niteesh...@gmail.com>>, Ryan Long
> >> > mailto:ryan.l...@oarcorp.com>>, Sebastian
> Huber
> >> >  sebastian.hu...@embedded-brains.de>>
> >> >
> >> > BUILD FAILED: failed make (failure)
> >> >
> >> > Sincerely,
> >> >  -The Buildbot
> >> >
> >> > ___
> >> > build mailing list
> >> > bu...@rtems.org 
> >> > http://lists.rtems.org/mailman/listinfo/build
> >> > 
> >> >
> >> > ___
> >> > devel mailing list
> >> > devel@rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
> >> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel