gdbarmsim: iostream fails.

Tue May 27 01:37:07 UTC 2014

On 27/05/2014 1:06 am, Joel Sherrill wrote:
>
> On May 26, 2014 7:27 AM, Chris Johns <chrisj at rtems.org> wrote:
>  >
>  > On 26/05/2014 12:44 pm, Chris Johns wrote:
>  > > Hi,
>  > >
>  > > I have pushed changes to the gdbarmsim. These changes plus the
> no-isr v2
>  > > patch give the following results:
>  > >
>  > > Passed:   448
>  > > Failed:     0
>  > > Timeouts:   2
>  > > Invalid:    1
>  > > -------------
>  > > Total:    451
>  > >
>  > > Timeouts:
>  > >   spfatal26.exe
>  > >   sp54.exe
>  > > Invalid:
>  > >   cxx_iostream.exe
>  > > Testing time: 0:04:20.781195
>  > >
>  > > The iostream sample test is failing because it clears the workspace and
>  > > it is exposing an issue. If I define BSP_GET_WORK_AREA_DEBUG in the
>  > > bsp.h the iostream test passes. With out BSP_GET_WORK_AREA_DEBUG the
>  > > executable is 256 bytes less and the workspace is 256 bytes larger.
> I do
>  > > not know why this makes a difference.
>  > >
>  > > The failure is due to the mknod call to create the console node failing
>  > > because the node name is all null characters. The call is
>  > > shared/console-polled.c:78:
>  > >
>  > >    status = rtems_io_register_name( "/dev/console", major, 0 );
>  > >
>  > > and inside rtems_io_register_name the name is empty.
>  > >
>  > > The call to _Workspace_Handler_initialization seems fine and the
>  > > workspace is cleared without a problem however the next call to
>  > > RTEMS_Malloc_Initialize results in the string being cleared.
>  > >
>  > > Any hints ?
>  > >
>  >
>  > It turns out the problem was the start.S in gdbarmsim was not compatible
>  > with the linkercmds files so I have replaced the old start.S with the
>  > common ARM start up code and pushed the change.
>
> Good catch!!
>

The bug match up so far is RTEMS 0, BSP 2. What this says to me is 
building a BSP is not good enough and if a BSP cannot be tested I 
question why we support it. I currently have no idea which BSPs we can 
test and which we cannot. It would be good to know.

>  > The results now are:
>  >
>  > Passed:   450
>  > Failed:     0
>  > Timeouts:   1
>  > Invalid:    0
>  > -------------
>  > Total:    451
>  >
>  > Timeouts:
>  >   spfatal26.exe
>  > Testing time: 0:04:18.455086
>
> 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.
>
> The MIPS has a generic gdb simulator and we could have a bsp for it.
>
> It adds coincidence without having 100s of boards and individual bsps no
> one cares about. Plus these are simple bsps.
>

I am still to be convinced having worked on this and looked at the gdb 
ARM sim code. It has not been updated to the latest ARM variants and 
seems to be loosing ground. The fact a non-aligned access is not caught 
lowers the value of the testing because there are bugs or issues that 
maybe missed. We really need a way to validate a simulator with real 
hardware to be of real value in terms of test results.

I am starting to wonder why bother running these BSPs if the variants of 
processor being tested are supported by qemu. When we have continuous 
integration running we I suspect we will have limited ability to run 
tests on each architecture and we will need to select ones that give the 
best value for the cpu time they consume and currently I do not see the 
gdb ARM simulator is not proving good value. If I remove spfatal26 from 
the tests and there are no timeouts the testing time becomes ...

Average test time: 0:00:00.195214
Testing time     : 0:01:27.846599

I do not know how this matches qemu on the same hardware.

The current situation is these bsps have rotted and fail. I have only 
been looking into the arm920 to see if an RTEMS failure is the reason 
and I am not seeing this.

> Did the set of bsp variants I created cover all multilibs for arm we
> have now?

Badly plus the list of variants is limited because the cortexA9 is not 
supported and there is no MMU. The arm1136jfs and arm1136js in the same 
way while the arm7tdmi and arm920 pass. I do not build the cortexa9 bsp 
because it fails due to missing instruction simulations.

The arm1136jfs and arm1136js fail because of this ...

$ arm-rtems4.11-run 
arm-rtems4.11/c/arm920/testsuites/fstests/fsdosfsname01/fsdosfsname01.exe
bdbuf_cache.lock = 1A010004

*** BEGIN OF TEST FSDOSFSNAME 1 ***
*** END OF TEST FSDOSFSNAME 1 ***

$ arm-rtems4.11-run 
arm-rtems4.11/c/arm1136jfs/testsuites/fstests/fsdosfsname01/fsdosfsname01.exe
bdbuf_cache.lock = 13010000

The code ends up in a fatal error in rtems_bdbuf_init because the 
bdbuf_cache.lock returned by the rtems_semaphore_create is not the 
correct class of id and this is detected when a call to claim it is 
made. I hacked the code to printk the id.

>
>  > I think spfatal26 should not be built for this BSP as I suspect the gdb
>  > simulator is not generating exceptions for misaligned accesses. Yes
> or no ?
>
> 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.
>

I do not understand. The spfatal26 test is the test for this case. It 
time outs because the accesses in the test do not trigger the expected 
exception. I suspect the simulator does not monitor this case but I have 
not checked.

Chris