[J-core] Debug jump log?

Rob Landley rob at landley.net
Fri Mar 3 20:23:06 EST 2017


On 02/25/2017 08:49 PM, BGB wrote:
> On 2/25/2017 6:40 PM, D. Jeff Dionne wrote:
>> On Feb 26, 2017, at 09:00, Rob Landley <rob at landley.net> wrote:
>>> How do you reconstruct "three functions back we did fifty-seven
>>> iterations of the loop that decided where to go next"?
>> You just reconstruct the jump log from the trace.   A register doesn't
>> help you with any of this, you need an external interface.  If you're
>> really (only) interested in looking at the 9k instruction cycles for
>> interrupts, the better approach is gprof.
>>
>> A trace log system is for reconstructing whole program flows,
>> including things like stalls and cache misses...
> 
> seems like it could be possible to have a feature to generate an
> interrupt whenever a branch occurs, so that the PC could be recorded?

Sure, but that would slow it down a lot. If a branch occurs every dozen
or so instructions (for loops, function calls, if statements...) and it
takes hundreds if not thousands of instructions to service an interrupt
(see "9000 cycles to service an interrupt in linux") then this isn't
necessarily much faster than single stepping?

In theory you could just single step the code and record all the
addresses (might need a jtag to do it in the kernel but all real
hardware targets have those), but only the jumps change program flow
(and thus need to be recorded to be able to work backwards). My
suggestion of writing them into to a buffer more or less assumed it
would write out filled cache lines, then deal with them in larger
batches later. It seemed a small enough feature not to eat too many
cells (it's basically one more memory location in the 0xabcdxxxx SOC
control block you write an address to when you start it and zero to when
you disable it, and maybe a second to indicate the interrupt to raise if
you don't want to hardwire it). That sounded like a small self-contained
VHDL project to me.

The first counter-argument was "why would you ever modify VHDL when you
could do an emulator". The second counter-argument was somebody else
once did a feature on some other platform and I should look that up
without actually knowing the name of the feature or (so far) being able
to find anyone who's ever used it. (Maybe it's "coldfire trace log
system"? No, that doesn't seem to find anything... there's a mention of
trace32 but the first hit on that is Lauterbach which is a type of jtag...)

*shrug* I stand corrected.

> say:
>     program is running, magic bit set to 1 (possibly in SR?);
>     hits a branch, triggers interrupt, clears SR bit;
>     interrupt handler records PC (or does whatever else);
>     return restores SR, which causes an interrupt on the next branch;
>     ...

Doable, but I don't see how it's simpler. (The "which interrupt does it
raise" question's not answered yet, and this depends more on the
software handler. I was trying for something I could see in operation
with only a trivial interrupt handler ala:

  int handler_count = 0;
  void handler(void)
  {
    if (++handler_count<8) *CONTROL = 0;
    IRET();
  }

I.E. I was trying for a simple vhdl change with effects visible from
Linux ("look, a log of jump locations!").

> off-hand, I don't really know what ColdFire does (not looked much into it).

Me neither. (Or rather I looked up a lot of what coldfire did circa
2006, and nobody ever even mentioned this feature's existence back then.)

Rob


More information about the J-core mailing list