<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 13, 2020 at 6:05 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 13/9/20 6:31 pm, Sebastian Huber wrote:<br>
> On 12/09/2020 01:31, Chris Johns wrote:<br>
>> On 12/9/20 12:10 am, Joel Sherrill wrote:<br>
>> [...]<br>
>>> Did we decide if there had to be an explicit configure<br>
>>> option to even use this API? Chris and I discussed this<br>
>>> as an idea to force a user to make a very conscious<br>
>>> decision to allow it.<br>
>> Sebastian did not like the idea and accepted that so not at the moment. The<br>
>> solution is better config management and we will monitor how this goes.<br>
> My point is that an API enable and the now implemented<br>
> maximum_thread_local_storage_size both lead to run-time errors of the new<br>
> directive. However, the maximum_thread_local_storage_size ensures that you don't<br>
> have an unexpected task storage configuration, for example a too small thread<br>
> stack size which could be difficult to debug.<br>
>><br>
>>> There does need to be documentation on the allocation<br>
>>> strategies, when to use, limitations, and particularly the<br>
>>> use of rtems-exeinfo to get the TLS size. This is one case<br>
>>> for sure where an RTEMS Tool needs explicit mention in<br>
>>> both the API and configure option sections.<br>
>> I agree. This one needs a little more than the others.<br>
> <br>
> I updated the ticket description:<br>
> <br>
> <a href="https://devel.rtems.org/ticket/3959" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3959</a><br>
<br>
I have added some updates for you to review.<br>
<br>
>>> I have had flashbacks to how often we got used to get questions<br>
>>> about why adding a sleep(1) in the middle of hello world locked<br>
>>> up. Then we added an option to say "does not need clock<br>
>>> driver" and the user questions stopped.  I would rather be a<br>
>>> bit aggressive on setup and avoid this for tasks with statically<br>
>>> allocated resources.<br>
>> I am concerned we have really difficult to debug issues that appear to be bugs<br>
>> but are weakness in the configuration.<br>
> I think it is now quite safe. If something is wrongly configured, then you get<br>
> an error status (RTEMS_INVALID_SIZE). You don't get problems like a suddenly too<br>
> small thread stack with a potential overflow.<br>
<br>
Yes I think we have suitable balance.<br></blockquote><div><br></div><div>We need a run-time error but this could still be detected on the host.</div><div><br></div><div>We have a configuration value (<span style="color:rgb(80,0,80)">maximum_thread_local_storage_s</span><span style="color:rgb(80,0,80)">ize)</span></div><div>which will have the user's desire and the actual value at link time.</div><div>I know in gdb you can inspect constant data without attaching to a</div><div>target or running so rtems-exeinfo should be able to do the same.</div><div>It knows the TLS size and should be able to check it against the </div><div>configured value. Post-link but pre-runtime. </div><div><br></div><div>This also makes me think that the manual explains the basic</div><div>theory of configuration parameters and our desire to default to</div><div>off/0/disabled or standards compliant. I don't know that we have</div><div>ever discussed our approach to errors.</div><div><br></div><div>+ confdefs does compile time consistency checks<br></div><div>+ link errors (SMP unsafe for sure)<br></div><div>+ post link consistency checks (new)<br></div><div>+ fatal errors before first context switch<br></div><div>+ run-time errors return status<br></div><div><br></div><div>We have a real set of design guidelines that we follow but I</div><div>know I have never done more than explained them as </div><div>individual points -- not as part of a unified strategy.</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chris<br>
</blockquote></div></div>