You should be able to trace execution near the point of the abort and
see what the kernel is trying to do and, ideally, in service of what
user program. The first part is fairly straightforward using
traceflags. I know the other part is possible by checking various
kernel data structures, but I don't know how to do it myself. You can
also hook up gdb using the remote debugging stub and look at the state
of the simulated system right before it aborts. Hooking up gdb should
also be straightforward using the instructions on the wiki, although
you'll need to make sure you stop the simulated system right before it
aborts.
Did you modify the kernel itself in any way, or are you just trying to
run your own user programs? If it's the later then there's a decent
chance you're running into a bug in M5 somewhere, although that's not
necessarily what's happening.
Gabe
Quoting Pritha Ghoshal <[email protected]>:
Hey
We are facing one strange issue. When we try to run some pre-compiled
benchmark(like surgespecweb) on our modified m5-code, we are not getting
these aborts. Its only when we run our self-compiled codes, we are getting
the aborts. We checked using m5term that the abort comes even before our
self-benchmark code starts executing. So, we presume this is in the kernel
part. Then in that case, our modules never get activated. We are hence not
able to understand why there is no error while running standard benchmark vs
the abort in our code in the kernel part.
We compiled our code using Crosscompiler available on the m5sim website and
then built it into the linux-image.
Are we missing something here??
Thanks
Pritha
On Mon, May 3, 2010 at 5:23 PM, Gabriel Michael Black <[email protected]
wrote:
That's probably that your read was to an address, 0xFFFFF00188, that wasn't
claimed by any memory, device, etc. That address may fall into a range with
a special purpose in Alpha, but I don't really know.
Gabe
Quoting Pritha Ghoshal <[email protected]>:
Hi
The assert says :
m5.opt: build/ALPHA_FS/cpu/simple/atomic.cc:496: Fault
AtomicSimpleCPU::read(Addr, T&, unsigned int) [with T = uint64_t]:
Assertion
`!pkt.isError()' failed.
And we have printf statements in the addlv instruction, so that whenever
it
executes, we get to know. Those statements are not being printed, so I
think
its not the addlv which is getting executed.
Thanks
Pritha
On Mon, May 3, 2010 at 3:29 PM, Gabriel Michael Black <
[email protected]
wrote:
What does the actual assert say? I'm wildly guessing a load crossed a
cache
line boundary, but it's hard to say from the backtrace. That addlv
instruction might actually be executed. You could try implementing a
pseudo
instruction which is much less likely to be used accidentally.
Gabe
Quoting Pritha Ghoshal <[email protected]>:
Hi,
We have been getting an abort while running M5 in full system mode. We
have
modified one instruction (addlv) to execute a different function,
because
that instruction is never used in the kernel part of the code. The
debugger
backtrace output is given below. Could anyone help us by suggesting
possible reasons for this abort?
Thanks
Pritha
#0 0x0000003423c30265 in raise () from /lib64/libc.so.6
#1 0x0000003423c31d10 in abort () from /lib64/libc.so.6
#2 0x0000003423c296e6 in __assert_fail () from /lib64/libc.so.6
#3 0x0000000000435a3e in read<uint64_t> (this=0x14e4950,
addr=1099510579592, da...@0x7fffffffd0e8, flags=512) at
build/ALPHA_FS/cpu/simple/atomic.cc:518
#4 0x0000000000456465 in AlphaISAInst::Hw_ldQ::execute (this=0x2051e70,
xc=0x14e4950, traceData=0x0) at build/ALPHA_FS/base/flags.hh:45
#5 0x0000000000425be6 in AtomicSimpleCPU::tick (this=0x14e4950) at
build/ALPHA_FS/base/refcnt.hh:83
#6 0x00000000006703d5 in EventQueue::serviceOne (this=<value optimized
out>) at build/ALPHA_FS/sim/eventq.cc:202
#7 0x00000000009f2f12 in simulate (num_cycles=9223372036854775807) at
build/ALPHA_FS/sim/simulate.cc:73
#8 0x0000000000a62fd7 in _wrap_simulate (self=<value optimized out>,
args=<value optimized out>) at
build/ALPHA_FS/python/swig/event_wrap.cc:4079
#9 0x000000343b2360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0
#10 0x000000343b29352c in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0
#11 0x000000343b295fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0
#12 0x000000343b29473f in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0
#13 0x000000343b294b66 in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0
#14 0x000000343b295fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0
#15 0x000000343b296032 in PyEval_EvalCode () from
/usr/lib64/libpython2.4.so.1.0
#16 0x000000343b295237 in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0
#17 0x000000343b295fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0
#18 0x000000343b29473f in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0
#19 0x000000343b295fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0
#20 0x000000343b296032 in PyEval_EvalCode () from
/usr/lib64/libpython2.4.so.1.0
#21 0x000000343b2b2729 in ?? () from /usr/lib64/libpython2.4.so.1.0
#22 0x0000000000791365 in m5Main (argc=<value optimized out>,
argv=<value
optimized out>) at build/ALPHA_FS/sim/init.cc:194
#23 0x000000000040854c in main (argc=7, argv=0x7fffffffe848) at
build/ALPHA_FS/sim/main.cc:57
--
Pritha Ghoshal
Texas A&M University
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
--
Pritha Ghoshal
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
--
Pritha Ghoshal
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
