<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 10, 2014 at 3:37 PM, Filip Pizlo <span dir="ltr"><<a href="mailto:fpizlo@apple.com" target="_blank">fpizlo@apple.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

I agree. I suspect that a better solution is to have the smarts for grokking the debug data inside LLVM, possibly borrowing logic from lldb. For starters clients like WebKit will want a machine-offset-to-debug-info map, which ain't rocket science - but currently parsing dwarf inside the LLVM client is the only way to do this afaict.<br>

</blockquote><div><br></div><div><div>I think what you're asking for is currently available in the C++ API: I'm not familiar with the C API, but my guess is a lack of a JITEventListener equivalent is what's caused you guys to do some contortions using the memory manager to inspect the MCJIT output (I think this also applies to finding the stackmaps sections).</div>

<div><br></div><div>So far our use of debug info is limited (only for user tracebacks) but we've been pretty happy with using a JITEventListener to call DIContext::getDWARFContext on the output, which at least for line table information, provides DWARF-parsing for us.  I guess it's inelegant to re-parse the data that was just generated, but so far it seems fine.</div>

<div><a href="https://github.com/dropbox/pyston/blob/master/src/codegen/unwinding.cpp#L111" target="_blank">https://github.com/dropbox/pyston/blob/master/src/codegen/unwinding.cpp#L111</a></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


Clients of optimizing JIT compilers are usually going to want to have some finer-grained control over how that JIT presents debug data to the debugger. Probably all that we want is: the JIT offers its debug data to its client, and the client decides if, and how, this data is presented to any debugger (lldb, gdb, or whatever). A reasonable default can of course be provided, if it leads to a good API.<br>


<br>
The MCJIT is currently ill suited to this kind of thing because it pretends to be a black box execution engine for LLVM IR. This black box then makes further assumptions that make sense for programs that target the C runtime. I believe that life would be easier if the task of generating code and the task of linking and executing it were better separated in the API.</blockquote>

<div><br></div><div>My impression is that the builtin gdb registration is just the default way of consuming the debug information -- I agree that the default behavior shouldn't come at the cost of flexibility for users who need something more customized, but it seems like things are close to the point that the GDB-registrar could be built using the C++ API, and it sounds like Lang's proposed changes would make it more possible.  The situation sounds different with the C API, but I think that might be an orthogonal issue of C-api-vs-C++-api, rather than MCJIT-internals-vs-api?</div>

<div><br></div><div>Personally I find the default gdb registration to be helpful in debugging of the JIT itself, even if it's not related to the task of providing our language-specific debug functionality.  Maybe one thing that would be nice to have is an API for disabling the GDB registration for performance reasons, which we would potentially make use of in release builds.  I'm not sure how much that would actually save, though, since I would assume the registration cost is dwarfed (pun intended?) by the compile time.</div>

<div><br></div><div>kmod </div></div></div></div>