<p dir="ltr"><br>
On May 26, 2014 7:27 AM, Chris Johns <chrisj@rtems.org> wrote:<br>
><br>
> On 26/05/2014 12:44 pm, Chris Johns wrote:<br>
> > Hi,<br>
> ><br>
> > I have pushed changes to the gdbarmsim. These changes plus the no-isr v2<br>
> > patch give the following results:<br>
> ><br>
> > Passed:   448<br>
> > Failed:     0<br>
> > Timeouts:   2<br>
> > Invalid:    1<br>
> > -------------<br>
> > Total:    451<br>
> ><br>
> > Timeouts:<br>
> >   spfatal26.exe<br>
> >   sp54.exe<br>
> > Invalid:<br>
> >   cxx_iostream.exe<br>
> > Testing time: 0:04:20.781195<br>
> ><br>
> > The iostream sample test is failing because it clears the workspace and<br>
> > it is exposing an issue. If I define BSP_GET_WORK_AREA_DEBUG in the<br>
> > bsp.h the iostream test passes. With out BSP_GET_WORK_AREA_DEBUG the<br>
> > executable is 256 bytes less and the workspace is 256 bytes larger. I do<br>
> > not know why this makes a difference.<br>
> ><br>
> > The failure is due to the mknod call to create the console node failing<br>
> > because the node name is all null characters. The call is<br>
> > shared/console-polled.c:78:<br>
> ><br>
> >    status = rtems_io_register_name( "/dev/console", major, 0 );<br>
> ><br>
> > and inside rtems_io_register_name the name is empty.<br>
> ><br>
> > The call to _Workspace_Handler_initialization seems fine and the<br>
> > workspace is cleared without a problem however the next call to<br>
> > RTEMS_Malloc_Initialize results in the string being cleared.<br>
> ><br>
> > Any hints ?<br>
> ><br>
><br>
> It turns out the problem was the start.S in gdbarmsim was not compatible <br>
> with the linkercmds files so I have replaced the old start.S with the <br>
> common ARM start up code and pushed the change. </p>
<p dir="ltr">Good catch!!<br></p>
<p dir="ltr">> The results now are:<br>
><br>
> Passed:   450<br>
> Failed:     0<br>
> Timeouts:   1<br>
> Invalid:    0<br>
> -------------<br>
> Total:    451<br>
><br>
> Timeouts:<br>
>   spfatal26.exe<br>
> Testing time: 0:04:18.455086</p>
<p dir="ltr">Awesome!! I have forgotten to pass along that the big value of these gdb simulators and their variations is that you get some testing on all multilib variants. This applies to the arm, h8, m32r, m32c. Sh, and v850 gdb simulator bsps off the top of my head. The pc386 is tested on qemu but we should consider the multilib coverage there. </p>
<p dir="ltr">The MIPS has a generic gdb simulator and we could have a bsp for it.</p>
<p dir="ltr">It adds coincidence without having 100s of boards and individual bsps no one cares about. Plus these are simple bsps.</p>
<p dir="ltr">Did the set of bsp variants I created cover all multilibs for arm we have now?<br></p>
<p dir="ltr">> I think spfatal26 should not be built for this BSP as I suspect the gdb <br>
> simulator is not generating exceptions for misaligned accesses. Yes or no ?</p>
<p dir="ltr">Seems quite likely but I don't know for sure. If this is the case, I would not add spfatal26 to the list but consider unaligned access generate fault and fatal error as a class of tests. At least it documents it.<br><br></p>
<p dir="ltr">> Chris<br>
> _______________________________________________<br>
> rtems-devel mailing list<br>
> rtems-devel@rtems.org<br>
> http://www.rtems.org/mailman/listinfo/rtems-devel<br>
</p>