On 9/16/2014 2:17 PM, Hesham Moustafa wrote:
On Tue, Sep 16, 2014 at 8:42 PM, Joel Sherrill
<joel.sherr...@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.sherr...@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.sherr...@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.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
