[J-core] Debug jump log?

[Tim Ansell]

I haven't really been following this thread fully, so sorry if this is off
target.

I do think the idea of exploring tracing, profiling or other debugging
features that work in a FPGA SoC which wouldn't make sense in silicon. A
couple of things which might be useful inspiration are;

OpenSoCDebug (http://opensocdebug.org/) -- they have a bunch of stuff
around tracing, including a Core Trace Module (CTM) & Software Trace Module
(STM) -- see http://opensocdebug.org/docs/overview/#trace-modules and the
rest of the docs. FYI There is a strong change that we will be looking at
adding OpenSoCDebug to litex and hopefully connect it to j1 when that is
integrated.

rr -- http://rr-project.org/, which is a super useful tool for recording a
failure once, then debug the recording, deterministically, as many times as
you want. It does need a couple of special instructions to be performant
however. See the following talk from slide 15 onwards --
http://rr-project.org/rr.html#15.0

Hope that helps,

Tim 'mithro' Ansell


On 4 March 2017 at 16:17, BGB <cr88192 at gmail.com> wrote:

> 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.
>
>
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20170304/8b250e68/attachment.html>