or1k test was .. Re: [PATCH] or1k: New cache manager.
Joel Sherrill
joel.sherrill at oarcorp.com
Tue Sep 16 19:21:32 UTC 2014
On 9/16/2014 2:17 PM, Hesham Moustafa wrote:
> On Tue, Sep 16, 2014 at 8:42 PM, Joel Sherrill
> <joel.sherrill at oarcorp.com> wrote:
>>
>> On 9/16/2014 1:34 PM, Hesham Moustafa wrote:
>>> On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill
>>> <joel.sherrill at oarcorp.com> wrote:
>>>> On 9/16/2014 12:54 PM, Hesham Moustafa wrote:
>>>>> Hi
>>>>>
>>>>> On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill
>>>>> <joel.sherrill at oarcorp.com> wrote:
>>>>>> I don't understand this but I got it applied.
>>>>>>
>>>>>> I manually edited the saved email to delete the preinstall.am
>>>>>> changes. I committed the rest. Then I ran bootstrap -p myself
>>>>>> and folded that into the rest of your patch.
>>>>>>
>>>>>> It should all be committed now.
>>>>>>
>>>>> Thanks for doing this, me too do not know what's wrong. BTW, commits
>>>>> are not mirrored on github since 4 days ago.
>>>>>
>>>>>> How about some new test results. :)
>>>>>>
>>>>> I did run one last night, no big progress since previous results :( Is
>>>>> there any tool, script, utility program or whatever that I can use to
>>>>> detect wrong memory access (i.e, stack overwrite, heap corruption,
>>>>> access to another task context)? I tried to add -fstack-protector-all
>>>>> to gcc, but QEMU did not get anything or core-dump, ticker just hangs.
>>>> I haven't checked into how gcc does its stack overwrite protection.
>>>>
>>>> The tests by themselves don't have these problems. The first
>>>> possible source is incorrect layout of sections to memory by
>>>> the linker script. There is some debug code in boot
>>>>
>>>> There used to be debug printk's in bspgetworkarea.c so you
>>>> could check if areas overlapped. That usually causes bad issues
>>>> though. Let's go through some basics:
>>>>
>>>> + Does hello world run and exit cleanly?
>>>>
>>> The output of Hello World is:
>>>
>>> *** BEGIN OF TEST HELLO WORLD ***
>>> Hello World
>>> *** END OF TEST HELLO WORLD ***
>>> Fatal Error 5.0 Halted
>>>
>>> From GDB:
>>>
>>> Breakpoint 1, _Terminate (
>>> the_source=RTEMS_FATAL_SOURCE_EXIT, is_internal=false, the_error=0)
>>> at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:39
>>> 39 _ISR_Disable_without_giant( level );
>>> (gdb) bt
>>> #0 _Terminate (
>>> the_source=RTEMS_FATAL_SOURCE_EXIT, is_internal=false, the_error=0)
>>> at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:39
>>> #1 0x0003b5f8 in rtems_shutdown_executive (result=0)
>>> at
>>> ../../../../../../rtems/c/src/../../cpukit/sapi/src/exshutdown.c:21
>>> #2 0x0003b350 in _exit (status=0)
>>> at
>>> ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:47
>>> #3 0x0002cc30 in exit (code=0)
>>> at ../../../../../gcc-4.8.3/newlib/libc/stdlib/exit.c:70
>>> #4 0x00002184 in Init (ignored=253816)
>>> at
>>> ../../../../../../../rtems/c/src/../../testsuites/samples/hello/init.c:33
>>> ---Type <return> to continue, or q <return> to quit---
>>> #5 0x0002c5b8 in _Thread_Handler ()
>>> at
>>> ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:192
>>> #6 0x0002c540 in _User_extensions_Thread_exitted (executing=0x40080)
>>> at
>>> ../../cpukit/../../../or1ksim/lib/include/rtems/score/userextimpl.h:243
>> This is normal and OK. Look at the arguments to _Terminate.
>>>> + How far does ticker get?
>>>>
>>> Ticker goes to the end:
>>>
>>> *** BEGIN OF TEST CLOCK TICK ***
>>> TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988
>>> TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988
>>> TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988
>>> TA1 - rtems_clock_get_tod - 09:00:05 12/31/1988
>>> TA2 - rtems_clock_get_tod - 09:00:10 12/31/1988
>>> TA1 - rtems_clock_get_tod - 09:00:10 12/31/1988
>>> TA3 - rtems_clock_get_tod - 09:00:15 12/31/1988
>>> TA1 - rtems_clock_get_tod - 09:00:15 12/31/1988
>>> TA2 - rtems_clock_get_tod - 09:00:20 12/31/1988
>>> TA1 - rtems_clock_get_tod - 09:00:20 12/31/1988
>>> TA1 - rtems_clock_get_tod - 09:00:25 12/31/1988
>>> TA3 - rtems_clock_get_tod - 09:00:30 12/31/1988
>>> TA2 - rtems_clock_get_tod - 09:00:30 12/31/1988
>>> TA1 - rtems_clock_get_tod - 09:00:30 12/31/1988
>>> *** END OF TEST CLOCK TICK ***
>>> Fatal Error 9.276564 Halted
>>>
>>> From GDB:
>>>
>>> (gdb) break _Terminate
>>> Breakpoint 1 at 0x19a68: file
>>> ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c, line
>>> 39.
>>> (gdb) break _OR1K_Exception_default
>>> Breakpoint 2 at 0x2686c: file
>>>
>>> ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c,
>>> line 22.
>>> (gdb) c
>>> The program is not being run.
>>> (gdb) target remote :50001
>>> Remote debugging using :50001
>>> 0x00000100 in _reset ()
>>> (gdb) c
>>> Continuing.
>>>
>>> Breakpoint 2, _OR1K_Exception_default (vector=6, frame=0x43854) at
>>>
>>> ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c:22
>>> 22 rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame );
>>> (gdb) bt
>>> #0 _OR1K_Exception_default (vector=6, frame=0x43854) at
>>>
>>> ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c:22
>>> #1 0x00026980 in jump_to_c_handler ()
>>> Backtrace stopped: frame did not save the PC
>>>
>>> vector 6 is _unalign exception.
>> Set a break point at exit() (I think) and rtems_shutdown_executive(). You
>> could start in the task which calls whatever kicks off the shutdown
>> sequence.
>> It looks like something in the shutdown procedure trips over something.
>> This might be easy to debug.
>>
> I did add just a function call to _CPU_Exception_frame_print(frame);
> from _OR1K_Exception_default(uint32_t vector, CPU_Exception_frame *frame)
> And ticker exits normally without even entering
> _OR1K_Exception_defaul as it did before. This is very weird. Does this
> mean that some areas of the code are overlapped from the linker
> script?
I doubt it. I suspect something unitialized or not aligned properly.
Set a breakpoint at
http://git.rtems.org/rtems/tree/testsuites/samples/ticker/tasks.c#n40
next over the print and then step through rtems_test_exit() and see
where it faults.
>> If the fault address is in the exception data, you can map that back to the
>> nm file and see what file that was in, then that might help.
>>>> + Have you tried the trick I suggested earlier to disable the
>>>> real clock tick driver, use the simulator idle tick code, and
>>>> disable all the tests that are known to fail that way. This
>>>> will eliminate the ISR code as an issue because you won't
>>>> have any (if console output if polled). See h8sim for
>>>> an example. Should be a Makefile.am change, adding
>>>> an include to the testsuite configuration file, building
>>>> and running.
>>>>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the devel
mailing list