[LLVMdev] Connecting JITted code to gdb

[Jeffrey Yasskin]

On Fri, Mar 27, 2009 at 4:40 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Fri, Mar 27, 2009 at 2:25 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
>> On Fri, Mar 27, 2009 at 3:48 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>>> Run with -debug-only=jit.
>>
>> OT: I take it the recommended model for tools that embed LLVM is for
>> them to accept all of LLVM's command line arguments on their own
>> command lines?
>
> Well, sort of... LLVM considers whatever you pass to
> ParseCommandLineOptions to be the command line, so you can tweak it
> depending on your needs.

Yes, so I'll probably add an environment variable to set this for my
use, since I keep getting told to pass --time-passes or
--debug-only=jit or --regalloc=local, and it'll be much easier to be
able to pass those parameters literally than to have to find the C++
interface to them each time. I might also try to expose
ParseCommandlineOptions as a Python function so I can add options
within the interpreter ... if that works.

>> For Python, it'd be much nicer to make this stuff
>> tweakable through a module at runtime, or even, for thread-safety
>> reasons, as a parameter to each call that cares about it.
>
> Command-line options are used for convenience in a variety of
> places... if there's some specific option that you need to modify at
> runtime that can't be changed in any other way, patches to change that
> are welcome.

I'll send you patches for these as I find them. I just wanted to point
out that this convenience for you guys is likely to be inconvenient
for people trying to embed LLVM.

> Also, IIRC, LLVM isn't threadsafe at the moment...

Right, but in the long term (2009Q3-4) we'll need to make Python's
runtime threadsafe, and before that I believe we'll want to optimize
in a background thread while a foreground thread is executing code
(which may itself try to compile more Python and call into LLVM) so
I'm assuming that I'll be working on making LLVM thread-safe at some
point. We'll use a global LLVM lock until then and just take the
latency hit.

Thanks,
Jeffrey