rtems_fatal() as inline in a header file
sebastian.huber at embedded-brains.de
Thu May 18 05:16:26 UTC 2017
On 18/05/17 01:08, Pham, Phong wrote:
> Hi Developers,
> is implemented as
> RTEMS_NO_RETURN RTEMS_INLINE_ROUTINE void rtems_fatal(
> rtems_fatal_source fatal_source,
> rtems_fatal_code error_code
> _Terminate( fatal_source, error_code );
> I suggest to move the implementation to fatal.c and remove
> RTEMS_INLINE_ROUTINE. I just don’t see a benefit to implement it as
The rtems_fatal() is an API function documented in the user manual. The
_Terminate() is an internal function.
> Besides, it has disadvantages. That is besides code size, during
> debugging, it simplifies the number of rtems_fatal symbol occurrences
> to 1. Don’t have to figure out which one is which.
Yes, for debugging you have to know that _Terminate() is the right
function to set the break point. This is not really great. Maybe we
should remove this indirection.
> bsp_fatal() is another one.
> Notice: This e-mail and any files transmitted with it may
> contain Data Device Corporation's privileged and proprietary
> information. It is intended solely for the use of the
> individual or entity to whom it is addressed. If you are not
> the named recipient of this transmission, any disclosure,
> copying, distribution or reliance on the contents of this
> message is prohibited. If you received this e-mail in error,
> please destroy it and any attached files and notify me
Do you take this message serious?
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel