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 <chr...@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@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
