RTEMS | Fix (#5239)

Joel Sherrill (@joel) gitlab at rtems.org
Tue Apr 22 14:40:36 UTC 2025



Joel Sherrill created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5239

Assignee: Joel Sherrill



## Summary
<!--
Please provide as much information as possible such as error messages or attaching logs
-->
When building many/most/all BSPs, the following warning is present. @opticron and I have investigated this before and assumed that it was an artefact of an inline helper not initialising all fields when not debug. GCC 14 gives a more thorough diagnostic and @opticron had the insight that the function in psignalclearsignals.c includes a test of a boolean argument indicating whether the signal clearing logic is executed inside a critical section or not. For some reason, GCC sees a path where the unlock could be called without the lock being called. Using the source on the 6 branch as a reference, this is the [locking conditional](https://gitlab.rtems.org/rtems/rtos/rtems/-/blame/6/cpukit/posix/src/psignalclearsignals.c?ref_type=heads#L87) and this is the [unlocking conditional](https://gitlab.rtems.org/rtems/rtos/rtems/-/blame/6/cpukit/posix/src/psignalclearsignals.c?ref_type=heads#L122).

The solution was to refactor the code inside the lock/unlock into a helper method so the expression checking if locking was needed is only tested once.

```
In file included from ../../../cpukit/include/rtems/score/isrlevel.h:43,
                 from ../../../cpukit/include/rtems/score/isr.h:41,
                 from ../../../cpukit/posix/src/psignalclearsignals.c:45:
In function 'arm_interrupt_enable',
    inlined from '_Thread_queue_Release' at ../../../cpukit/include/rtems/score/threadqimpl.h:829:3,
    inlined from '_POSIX_signals_Release' at ../../../cpukit/include/rtems/posix/psignalimpl.h:106:3,
    inlined from '_POSIX_signals_Clear_signals' at ../../../cpukit/posix/src/psignalclearsignals.c:123:5:
../../../cpukit/score/cpu/arm/include/rtems/score/cpu.h:357:3: warning: 'queue_context.Lock_context.Lock_context.isr_level' may be used uninitialized [-Wmaybe-uninitialized]
  357 |   __asm__ volatile (
      |   ^~~~~~~
../../../cpukit/posix/src/psignalclearsignals.c: In function '_POSIX_signals_Clear_signals':
../../../cpukit/posix/src/psignalclearsignals.c:67:31: note: 'queue_context.Lock_context.Lock_context.isr_level' was declared here
   67 |   Thread_queue_Context        queue_context;
      |                               ^~~~~~~~~~~~~
```

NOTE: This may indicate that GCC was doing some of the path analysis incorrectly. A gcc ticket will be filed also.

## Steps to reproduce


### Pre-set options

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5239
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250422/a7bc4960/attachment.htm>


More information about the bugs mailing list