On Sun, Sep 13, 2020 at 6:05 PM Chris Johns <chr...@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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
