This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 5/9/2016 3:41 PM, Ian Lance Taylor wrote:
On Mon, May 9, 2016 at 1:07 PM, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:One complication on RTEMS which is a single process, multi-threaded RTOS is that we can no longer check the stack bounds. For threads, we know where the stack memory is and the range for each thread. For ucontext_t, it seems this knowledge is unknown to the RTOS. Thus it would become the responsibility of the run-time using ucontext_t to put in fence patterns and check those.On RTEMS and similar systems, you could write makecontext to register the stack (whose start and length are known to the function) with the RTOS.
Ahh... slow today. swapcontext() would have to work with the stack checker.Interesting.. the stack usage reporting would have to be taught
about the ucontext_t's in the system and report those as well. Am I missing something or is there no way to know when a context goes out of existence in the API?
Ian
--joel
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |