[PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

[Joel Sherrill]

On Sun, Sep 13, 2020 at 6:05 PM Chris Johns <chrisj at rtems.org> wrote:

> On 13/9/20 6:31 pm, Sebastian Huber wrote:
> > On 12/09/2020 01:31, Chris Johns wrote:
> >> On 12/9/20 12:10 am, Joel Sherrill wrote:
> >> [...]
> >>> Did we decide if there had to be an explicit configure
> >>> option to even use this API? Chris and I discussed this
> >>> as an idea to force a user to make a very conscious
> >>> decision to allow it.
> >> Sebastian did not like the idea and accepted that so not at the moment.
> The
> >> solution is better config management and we will monitor how this goes.
> > My point is that an API enable and the now implemented
> > maximum_thread_local_storage_size both lead to run-time errors of the new
> > directive. However, the maximum_thread_local_storage_size ensures that
> you don't
> > have an unexpected task storage configuration, for example a too small
> thread
> > stack size which could be difficult to debug.
> >>
> >>> There does need to be documentation on the allocation
> >>> strategies, when to use, limitations, and particularly the
> >>> use of rtems-exeinfo to get the TLS size. This is one case
> >>> for sure where an RTEMS Tool needs explicit mention in
> >>> both the API and configure option sections.
> >> I agree. This one needs a little more than the others.
> >
> > I updated the ticket description:
> >
> > https://devel.rtems.org/ticket/3959
>
> I have added some updates for you to review.
>
> >>> I have had flashbacks to how often we got used to get questions
> >>> about why adding a sleep(1) in the middle of hello world locked
> >>> up. Then we added an option to say "does not need clock
> >>> driver" and the user questions stopped.  I would rather be a
> >>> bit aggressive on setup and avoid this for tasks with statically
> >>> allocated resources.
> >> I am concerned we have really difficult to debug issues that appear to
> be bugs
> >> but are weakness in the configuration.
> > I think it is now quite safe. If something is wrongly configured, then
> you get
> > an error status (RTEMS_INVALID_SIZE). You don't get problems like a
> suddenly too
> > small thread stack with a potential overflow.
>
> Yes I think we have suitable balance.
>

We need a run-time error but this could still be detected on the host.

We have a configuration value (maximum_thread_local_storage_size)
which will have the user's desire and the actual value at link time.
I know in gdb you can inspect constant data without attaching to a
target or running so rtems-exeinfo should be able to do the same.
It knows the TLS size and should be able to check it against the
configured value. Post-link but pre-runtime.

This also makes me think that the manual explains the basic
theory of configuration parameters and our desire to default to
off/0/disabled or standards compliant. I don't know that we have
ever discussed our approach to errors.

+ confdefs does compile time consistency checks
+ link errors (SMP unsafe for sure)
+ post link consistency checks (new)
+ fatal errors before first context switch
+ run-time errors return status

We have a real set of design guidelines that we follow but I
know I have never done more than explained them as
individual points -- not as part of a unified strategy.

--joel

>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200914/4672c106/attachment.html>