Just saw that the gem5 process gets the SIG_TRAP not the simulated process... Still not sure why. It also happened to me at another place and I can avoid it by disabling the breakpoint I set or breaking at a later point in the program.
On Mon, Mar 26, 2012 at 9:51 AM, Samuel Hitz <[email protected]> wrote: > I'm not running a linux kernel, I'm porting Barrelfish-OS to ARMv7. I ran > gem5 in debug mode and dropped into the break_event. A backtrace gave me > this > > Program received signal SIGTRAP, Trace/breakpoint trap. > > > 0x00007ffff6460c57 in kill () from /lib/libc.so.6 > > > (gdb) bt > > > #0 0x00007ffff6460c57 in kill () from /lib/libc.so.6 > > > #1 0x000000000131d8ed in Debug::breakpoint () at > build/ARM/base/debug.cc:56 > > #2 0x0000000001410ab2 in BreakPCEvent::process (this=0x348c780, > tc=0x34dc490) at build/ARM/cpu/pc_event.cc:137 > > #3 0x000000000140ff68 in PCEventQueue::doService (this=0x348c1e0, > tc=0x34dc490) at build/ARM/cpu/pc_event.cc:102 > > #4 0x000000000142ca32 in PCEventQueue::service (this=0x348c1e0, > tc=0x34dc490) at build/ARM/cpu/pc_event.hh:107 > > #5 0x000000000142ca84 in BaseSimpleCPU::checkPcEventQueue > (this=0x34da230) at build/ARM/cpu/simple/base.hh:98 > > #6 0x000000000142b485 in AtomicSimpleCPU::tick (this=0x34da230) at > build/ARM/cpu/simple/atomic.cc:446 > > #7 0x0000000001427b90 in AtomicSimpleCPU::TickEvent::process > (this=0x34da4c0) at build/ARM/cpu/simple/atomic.cc:59 > > #8 0x0000000001382ebc in EventQueue::serviceOne (this=0x2704940) at > build/ARM/sim/eventq.cc:204 > > #9 0x00000000013ceb21 in simulate (num_cycles=9223372036854775807) at > build/ARM/sim/simulate.cc:73 > > #10 0x0000000000445a99 in _wrap_simulate__SWIG_0 (args=0x3320e10) at > build/ARM/python/swig/event_wrap.cc:4475 > > #11 0x0000000000445c56 in _wrap_simulate (self=0x0, args=0x3320e10) at > build/ARM/python/swig/event_wrap.cc:4525 > > #12 0x00007ffff74da1b9 in PyEval_EvalFrameEx () from > /usr/lib/libpython2.7.so.1.0 > > #13 0x00007ffff74db86f in PyEval_EvalCodeEx () from > /usr/lib/libpython2.7.so.1.0 > > #14 0x00007ffff74d9a9e in PyEval_EvalFrameEx () from > /usr/lib/libpython2.7.so.1.0 > > #15 0x00007ffff74da4a8 in PyEval_EvalFrameEx () from > /usr/lib/libpython2.7.so.1.0 > > #16 0x00007ffff74db86f in PyEval_EvalCodeEx () from > /usr/lib/libpython2.7.so.1.0 > > #17 0x00007ffff74db9a2 in PyEval_EvalCode () from > /usr/lib/libpython2.7.so.1.0 > > #18 0x00007ffff74d9d20 in PyEval_EvalFrameEx () from > /usr/lib/libpython2.7.so.1.0 > > #19 0x00007ffff74db86f in PyEval_EvalCodeEx () from > /usr/lib/libpython2.7.so.1.0 > > #20 0x00007ffff74d9a9e in PyEval_EvalFrameEx () from > /usr/lib/libpython2.7.so.1.0 > #21 0x00007ffff74db86f in PyEval_EvalCodeEx () from > /usr/lib/libpython2.7.so.1.0 > #22 0x00007ffff74db9a2 in PyEval_EvalCode () from > /usr/lib/libpython2.7.so.1.0 > #23 0x00007ffff74f5cac in run_mod () from /usr/lib/libpython2.7.so.1.0 > #24 0x00007ffff74f689d in PyRun_StringFlags () from > /usr/lib/libpython2.7.so.1.0 > #25 0x000000000138ca67 in m5Main (argc=3, argv=0x7fffffffe0e8) at > build/ARM/sim/init.cc:256 > #26 0x000000000040b00b in main (argc=3, argv=0x7fffffffe0e8) at > build/ARM/sim/main.cc:57 > > I went through the corresponding gem5 code and I'm not sure why you call > 'Debug::breakpoint()' in 'process', because I don't set a breakpoint at the > point, where this break_event triggers. The thing is, this sends a SIG_TRAP > to the kernel, but since I've not yet setup the exception handlers, this > fails obviously. It seems to have something to do with the breakpoint I > set, because when I set a breakpoint after the critical code section or > break before and remove the breakpoint afterwards, everything goes well. > > Maybe you can shed some light on the behavior of gem5? > > Best, > > Samuel > > On Mon, Mar 26, 2012 at 4:20 AM, Steve Reinhardt <[email protected]> wrote: > >> Strange... have you modified the kernel? Perhaps the hook that's trying >> to intercept the panic call is latching on to the wrong PC for some reason. >> If you run from gdb the break_event should drop you into it and perhaps >> you can poke around and figure out why you're there. >> >> Steve >> >> >> ---------- Forwarded message ---------- >> From: Samuel Hitz <[email protected]> >> Date: Sun, Mar 25, 2012 at 4:25 AM >> Subject: Re: [gem5-users] break event panic triggered >> To: gem5 users mailing list <[email protected]> >> >> >> Yes I'm running in FS mode. The thing is, it happens pretty early in the >> boot process, where I install exception handlers, so there is no 'panic' >> call or handler at that time. >> >> >> On Sun, Mar 25, 2012 at 7:44 AM, Steve Reinhardt <[email protected]>wrote: >> >>> Are you running in full-system mode? This could indicate a kernel panic >>> on your simulated system. We trap the panic call and generate a break >>> event, since generally it's more useful to look around at the point of the >>> panic than to simulate the kernel running through its panic handling code. >>> >>> Steve >>> >>> On Fri, Mar 23, 2012 at 7:10 AM, Samuel Hitz <[email protected]>wrote: >>> >>>> Hi there, >>>> >>>> I encounter a >>>> >>>> 9035000: system.cpu.break_event: break event panic triggered >>>> >>>> Now my question is, what could possibly cause such a panic? >>>> I can trace the execution of the program up to the point, where this >>>> happens. Strangely enough, if I just jump past this small part of the >>>> program causing this, the execution can go on. The jumped part does some >>>> writes to memory but it doesn't overwrite code or something. >>>> There is no other relevant output of gem5 before this happens. >>>> >>>> Any help is much appreciated. >>>> >>>> Best, >>>> >>>> Samuel >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
