On 20/9/17 3:48 pm, Sebastian Huber wrote: > There are some checks that help to debug broken applications. For example the > heap protection, the deadlock detection, the file descriptor reference > counting > and simple parameter validation.
Yes I agree some of these are useful and I am not against mechanisms being added to allow support however I feel grouping support that is consider user friendly under RTEMS_DEBUG is bending it's usage and leaves the user in an awkward position of leaving the option on or off for production. Adding more compile options increases the time we need to spent testing the combinations. A rtems-bsp-builder run with `--profile=everything --build=all` has 1552 separate builds and 2.2M object files and took almost 7hr on a fast machine. That is 16 seconds a BSP on average. I am not offering a solution here, just raising the issues I see. How we name this is important. > A correct application doesn't need these checks > and simply encounters a run-time penalty and some space overhead, but it > should > be tolerable. That is true if what is controlled by the switch is what we say it is. This becomes a key issue for anyone auditing the code. > However, some internal consistency checks, e.g. for the SMP locks, > are quite heavy weight and really hurt the performance. Understood. > From my experience SMP applications are quite sensitive to the performance of > mutexes. For example, the glibc POSIX mutex is heavily performance optimized, Agreed. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
