
<html><head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

<meta name="Generator" content="Microsoft Exchange Server">

<!-- converted from text -->

<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style></head>

<body>

<body><p dir="ltr">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.</p><div class="quote">On Apr 27, 2014 6:45 PM, Chris Johns <chrisj@rtems.org> wrote:<br type="attribution"></div></body>

<font size="2"><div class="PlainText">On 27/04/2014 10:30 pm, Sebastian Huber wrote:<br>

> On 04/27/2014 02:13 PM, Chris Johns wrote:<br>

>> Splitting the call to _CPU_Fatal_halt out into a separate function<br>

>> allows the rtems-test gdb support the ability to halt once the<br>

>> _Terminate function has completed it's work.<br>

>><br>

>> This change allows the BeagleBoard xM BSP to pass a number of<br>

>> important tests.<br>

><br>

> I don't find a BeagleBord BSP in the tree.<br>

><br>

<br>

Ben has nicely answered this. Thanks Ben.<br>

<br>

> In case the BSP has to do fancy things during termination, why don't you<br>

> do this in bsp_reset() or bsp_fatal_extension()?<br>

><br>

> I guess the bsp.h has no:<br>

><br>

> #include <bsp/default-initial-extension.h><br>

><br>

<br>

I do not know and from a testing point of view I do not think it should <br>

it matter.<br>

<br>

The _Terminate function needs to be split so we can set a break point <br>

and have it hit in the default case. Setting a break point based on a <br>

line number in a file is far too fragile. We need the extensions to run <br>

so the END marker is output in a few tests.<br>

<br>

I added the weak part because it costs nothing to add. Maybe we should <br>

consider the patch as 2 parts.<br>

<br>

> The way to control the termination sequence is via user extensions and<br>

> not weak functions.<br>

<br>

Pros and cons ... If the point is having only one way, that is a valid <br>

comment. On the other hand weak functions cost little if anything and it <br>

lets the BSP designer have control over adding the required BSP <br>

specialisation. Weak functions can be abused and that should be avoided.<br>

<br>

I have now taken a closer look at this default extension approach. The <br>

<bsp/default-initial-extension.h> fights the cpukit and bsp separation <br>

and adds new rules to the use of confdefs.h that I do not think are <br>

being enforced. If a new user to RTEMS uses a BSP and creates an app <br>

using confdefs.h and does not first include bsp.h or <br>

default-initial-extension.h the resulting BSP code linked in is not what <br>

the BSP designer intended and as far as I can see there is not <br>

indication something is wrong.<br>

<br>

Chris<br>

_______________________________________________<br>

rtems-devel mailing list<br>

rtems-devel@rtems.org<br>

<a href="http://www.rtems.org/mailman/listinfo/rtems-devel">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>

</div></font>

</body>

</html>