[PATCH] score: Split _Terminate and call _Terminate_CPU_Fatal_halt.

Joel Sherrill Joel.Sherrill at OARcorp.com
Mon Apr 28 02:01:10 UTC 2014


I do not know if this is helpful but the sim-scripts gdb startup file sets breakpoints on bad places to get to like __assert. the one on _Terminate is conditional on there being non-zero status.

On Apr 27, 2014 6:45 PM, Chris Johns <chrisj at rtems.org> wrote:
On 27/04/2014 10:30 pm, Sebastian Huber wrote:
> On 04/27/2014 02:13 PM, Chris Johns wrote:
>> Splitting the call to _CPU_Fatal_halt out into a separate function
>> allows the rtems-test gdb support the ability to halt once the
>> _Terminate function has completed it's work.
>>
>> This change allows the BeagleBoard xM BSP to pass a number of
>> important tests.
>
> I don't find a BeagleBord BSP in the tree.
>

Ben has nicely answered this. Thanks Ben.

> In case the BSP has to do fancy things during termination, why don't you
> do this in bsp_reset() or bsp_fatal_extension()?
>
> I guess the bsp.h has no:
>
> #include <bsp/default-initial-extension.h>
>

I do not know and from a testing point of view I do not think it should
it matter.

The _Terminate function needs to be split so we can set a break point
and have it hit in the default case. Setting a break point based on a
line number in a file is far too fragile. We need the extensions to run
so the END marker is output in a few tests.

I added the weak part because it costs nothing to add. Maybe we should
consider the patch as 2 parts.

> The way to control the termination sequence is via user extensions and
> not weak functions.

Pros and cons ... If the point is having only one way, that is a valid
comment. On the other hand weak functions cost little if anything and it
lets the BSP designer have control over adding the required BSP
specialisation. Weak functions can be abused and that should be avoided.

I have now taken a closer look at this default extension approach. The
<bsp/default-initial-extension.h> fights the cpukit and bsp separation
and adds new rules to the use of confdefs.h that I do not think are
being enforced. If a new user to RTEMS uses a BSP and creates an app
using confdefs.h and does not first include bsp.h or
default-initial-extension.h the resulting BSP code linked in is not what
the BSP designer intended and as far as I can see there is not
indication something is wrong.

Chris
_______________________________________________
rtems-devel mailing list
rtems-devel at rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140427/94010fc7/attachment.html>


More information about the devel mailing list