[llvm-dev] ORC JIT Weekly #7 -- JITEventListener support and Swift Immediate Mode Migration

Frank Tetzel via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 17 11:32:48 PDT 2020


> On 2020-03-09 21:20:44 +0100, Frank Tetzel via llvm-dev wrote:
> > I think, debugging and profiling support is very important for a JIT
> > engine. I could never get it to work with older LLVM versions. Is
> > there example code somewhere available?
> 
> Since I added the perf listener I probably can help you with that.
> What exactly was the problem you were hitting?
> 
> I don't have isolated example code, but it really shouldn't take much
> code to set up the event listener. All that PG (which is what I added
> the perf listener for) is doing is:
> https://github.com/postgres/postgres/blob/master/src/backend/jit/llvm/llvmjit.c#L676
> 
> When taking a profile of a program you need to specify -k 1 to perf,
> to have compatible clocks. E.g. you need to take it like
> $ perf record -k 1 --call-graph dwarf -o /tmp/perf.data -p 22950
> and then
> you need to inject the JIT information into the profile:
> $ perf inject -v --jit -i /tmp/perf.data -o /tmp/perf.jit.data
> after that perf.jit.data is a perf profile enriched with the necessary
> information, and can normally be inspected by perf report (using -i
> /tmp/perf.jit.data).

I followed all these steps. During recording, dump files are created in
~/.debug/. Unfortunately, perf report never allowed me to "zoom" into
the jitted function and get an assembly view with profile information.
Either inject or report do not work for some reason. The tools work
fine when I'm using a different JIT library (AsmJit). Maybe it's just
some path issue. I do not really like that the dump files are created
in ~/.debug/.

Last time I tried it was some months ago with LLVM 9. I'll try it
shortly with LLVM trunk/master and report back.


> If you want debug information within the JITed code (e.g. to see
> associated source lines or such) that's a separate task - you need to
> emit debug information, which is unrelated to the listener itself.

Profiling on the assembly level would already be very helpful.

Best regards,
Frank


More information about the llvm-dev mailing list