[J-core] Debug jump log?

[BGB]

On 3/3/2017 7:23 PM, Rob Landley wrote:
> 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.

could be, what I had originally imagined was something similar to the 
single-step feature in x86 (trap flag), but with the tweak of being able 
to (optionally?) ignore non-branch instructions. then again, I could 
have probably just said "like the x86 trap flag".

had imagined the ISR probably doing something similar to the buffer idea 
you had mentioned, but didn't think of having this part implemented in 
hardware (or fully understand the suggestion of doing so). if a trap 
ISR, would ideally want a minimalist interrupt handler to limit overhead 
(ideally with no direct dependence on kernel facilities if used on the 
kernel).

yep, "every dozen or so instructions" falls within the average-case 
range I have been seeing.


but, dunno really, not entirely thought through the idea.


<snip>

ok, just nothing really to add.