Adding GDB BSPs to rtems-tester

[Joel Sherrill]

On Sun, Mar 22, 2020, 8:43 AM Gedare Bloom <gedare at rtems.org> wrote:

> On Sun, Mar 22, 2020 at 1:40 AM Niteesh G. S. <niteesh.gs at gmail.com>
> wrote:
> >
> > I built mips jmr3904. I was able to run rtems-run and rtems-test on it.
> > But cdtest.exe fails.
> > *** TESTING C++ EXCEPTIONS ***
> > mips-core: 1 byte read to unmapped address 0x2ed31 at 0x880290a4
> > Program received signal SIGBUS, Bus error.
> > 0x88028fe4 in strlen ()
> > What is causing this error?
> This shows that the strlen function is accessing a bad address
> (0x2ed31). In fact, this is part of the value of the jmr3904 simulator
> and why we want to get it working for routine testing, because it can
> catch bad memory errors.
>
> > I tried running this manually on GDB. On forcefully continuing.
> The next step is not to forcefully continue, but to work backwards
> from the failure in GDB. print a stack backtrace ('bt' command) to see
> how it got to strlen. Look at the values of the registers you can
> observe. Compare with the code in the example and trace the example
> code forward along the path shown by the backtrace. Use GDB to
> investigate the stack frames ('up' and 'down' commands).
>
> > Warning, resuming with mismatched exception signal (7 vs 10)
> After an unmapped address access, nothing else that executes is going
> to be valid.
>
> > Unhandled exception 7
> > sr: 0x536936196  cause: 0x00029724 --> Data Bus Error
> >
> > *** FATAL ***
> > fatal source: 1 (INTERNAL_ERROR_RTEMS_API)
> > fatal code: 9800724312699699200 (0x100000000)
> > RTEMS version: 5.0.0.37e7cc5f4ce7ed46b5ea2de56d9066d121d851cb-modified
> > RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib
> fbaa096)
> > executing thread ID: 0x08a010001
> > executing thread name: CTOR
> >
> > Is this problem with the BSP or simulator? And how can I fix this?
>
> Most likely it is a problem with newlib.
>

Random guess. A section, stack, or malloced memory is not properly aligned.

--joel

>
> >
> > On Sat, Mar 21, 2020 at 11:33 PM Joel Sherrill <joel at rtems.org> wrote:
> >>
> >>
> >>
> >> On Sat, Mar 21, 2020 at 10:38 AM Niteesh G. S. <niteesh.gs at gmail.com>
> wrote:
> >>>
> >>> Which architecture should I try then? Maybe powerpc or mips? If you
> have any
> >>> of them already built can you please try them out? Building everything
> from
> >>> source takes a lot of time in my dev machine.
> >>>
> >>> On Sat, Mar 21, 2020 at 6:41 PM Gedare Bloom <gedare at rtems.org> wrote:
> >>>>
> >>>> On Sat, Mar 21, 2020 at 12:54 AM Niteesh G. S. <niteesh.gs at gmail.com>
> wrote:
> >>>> >
> >>>> > On Thu, Mar 19, 2020 at 11:43 PM Gedare Bloom <gedare at rtems.org>
> wrote:
> >>>> >>
> >>>> >> On Thu, Mar 19, 2020 at 11:56 AM Niteesh G. S. <
> niteesh.gs at gmail.com> wrote:
> >>>> >> >
> >>>> >> > Hello,
> >>>> >> >
> >>>> >> > While looking for small tasks to take up, Gedare mentioned about
> adding GDB BSPs
> >>>> >> > to rtems-tester. Can some please explain a bit more of what has
> to be done? I guess
> >>>> >> > we have to write configuration files for BSPs that support
> simulation in GDB. If so, how
> >>>> >> > could I find those BSPs, do I have to individually look at all
> the BSPs?
> >>>> >> >
> >>>> >> As I said off-list, I don't know if there's a list of GDB BSPs,
> but I
> >>>> >> know of at least:
> >>>> >> powerpc/psim
> >>>> >> mips/jmr3904
> >>>> >> moxie/moxiesim
> >>>> >> arm/gdbarmsim
> >>>> >> sh/shsim
> >>>> >>
> >>>> >> I have no idea what any of their statuses are or if they are
> expected
> >>>> >> to work. The first step would be building them and see if they run
> >>>> >> anything. After that, you should look at the existing tester
> scripts for
> >>>> >> some targets:
> >>>> >>   rtems-tools.git/tester/rtems/testing/bsps
> >>>> >> I see scripts for most of what I listed above, so the next step
> would
> >>>> >> be trying to run them via tester and see if it works.
> >>>> >
> >>>> >
> >>>> > I built the simsh1 BSP but couldn't get it running. Before trying
> it with rtems-run
> >>>> > and rtems-test I tried manually loading it in the simulator. But
> gdb doesn't respond
> >>>> > as soon as I execute the run command. The only way to exit it was
> using ctrl-c and GDB
> >>>> > responds with
> >>>> > sim_events_schedule_after_signal - buffer overflow
> >>>> > Quit
> >>>> > Aborted (core dumped)
> >>>> > I tried setting breakpoints within GDB but it never seems to hit
> them. I tried running the
> >>>> > examples through rtems-test results in ta imeout.
> >>>> >
> >>>> > Due to the slow internet connection and slow development machine, I
> could only build
> >>>> > and test a few BSPs. In case if anyone has an already built tool
> suite and BSP for the
> >>>> > mentioned arch please try them out.
> >>>> >
> >>>> I don't know that anyone uses this architecture. Don't spend too much
> >>>> effort trying to debug the simulator :)
> >>
> >>
> >> mips jmr3904 and powerpc psim should work well.
> >>
> >> I agree with Gedare, spending a lot of time on the SH isn't high payoff.
> >> I'm glad for the report but there could be bitrot in the simulator or
> BSP.
> >>
> >>>>
> >>>>
> >>>> >> BTW: Did I mention adding these to tester, or did I mention
> creating
> >>>> >> build sets for them? Anyway, I think the GDB simulator builds by
> >>>> >> default with the toolchain, so there is no difference between a BSP
> >>>> >> buildset (such as for jmr3904) and one that supports running on
> GDB.
> >>>> >> At least, I think so. It is worth verifying.
> >>>> >>
> >>>> >> Gedare
> >>>> >>
> >>>> >> > Thank you,
> >>>> >> > Niteesh.
> >>>> >> > _______________________________________________
> >>>> >> > devel mailing list
> >>>> >> > devel at rtems.org
> >>>> >> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200322/b1cde3ba/attachment-0001.html>