How to break the gem5 executable in GDB at a the nth instruction?

Question

Using --debug-flags ExecAll tracing, I found that there is a bug at the Nth instruction, which happens at the Nth line of the log.

Is there an easy way to break specifically at that instruction to debug it in GDB and view gem5's internal state?

Answer 1

The simplest approach is to use --debug-break as shown at: schedBreak(<tick>) gdb debugging function not working

That makes gem5 raise a signal at a given simulation, which GDB stops at by default. You can determine what simulation time corresponds to your instruction by looking at an --debug-flags ExecAll trace beforehand.

You will want to break on the tick much more often than on the Nth instructions, in particular since gem5 simulates the instruction pipeline, and therefor there can be multiple instructions in flight at the same time.

Alternatively, from GDB your point of interest sees the ExecutionContext object, which if often called xc, you can just add a conditional breakpoint like:

b MyClass::myFunction if xc->numInsts.data()->value() == <n> - 2

The -2 is needed because this index is zero based, and because the tick increments after instruction execution.

You can also find the tick time rather than instruction count with:

p xc->cpu->tick

or from the other commonly available ThreadContext object with:

p tc->baseCpu->tick

You generally want to do this from the ::tick() function of your CPU model of interest.

For AtomicSimpleCPU::tick() you could also break just before the second instruction with:

b AtomicSimpleCPU::tick if (*threadInfo[curThread]).numInst == 1

Or to break at a given tick, say 1000 (500 is the one before it):

b AtomicSimpleCPU::tick if tick == 500

Two other important break locations are at the main event loop when an event is executed:

b EventQueue::serviceOne() if head->when() == 1000

and the event scheduling target point:

b EventQueue::schedule if when == <target-time>
b EventQueue::reschedule if when == <target-time>

or for the time of schedule itself:

b EventQueue::schedule if _curTick == 1000
b EventQueue::reschedule if _curTick == 1000

Together with reverse debugging and:

--debug-flags Event

these event breakpoints will actually allow you to understand what gem5 is doing.

Note however that conditional breakpoints significantly slow down simulation unfortunately... arghh.

Another useful technique to have in mind is that you can do a run that stops shortly after the point of interest with:

-m <tick>

and then reverse debug back to the exact point of interest, possibly conditionally since now you will be close the the point of interest, so the performance loss will not be a huge problem. You can then just continue going back to the root cause.

Tested in gem5 9f247403e558977738b5911a45e5776afff87b1a.