[lldb-dev] lldb -- architecture level question -- linux v. darwin

[Jason E. Aten]

On Wed, Mar 16, 2011 at 2:18 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote:

>  If your use
> case is to do your own codegen and then throw some debug info over to
> the debugger, you'll have to be able to generate it (ie DWARF) and
> wrap it in the native object file for your platform in memory.  LLVM
> has some code to produce ELF, so I used that.*  At the time, I wasn't
> worried about other platforms.
>
> * Actually, that code for ELF generation is old and this interface is
> the last user of it so far as I know.


Great!  Yes, that is exactly my use case: Suppose I am stopped in the middle
of code, in LLDB,
with a variable that has a debugger symbol for a collection that needs to be
sorted differently than it is at the moment, in order
to determine if the code is producing the correct collection.

So I'd like to be able to define a new sorting function from the command
line (like the Clang Expression stuff I think let's one do), but
in this case it's in a non-C++ language that I have a compiler for.  Then
JIT-compile that new "how to sort" function, and have it talk to already
defined data and code, and have it run from the within the debugger. After
the sort, be able (from LLDB) be able to re-inspect the
output of the collection.

Does this make sense?  Are there obstacles that I'm not envisioning?  Any
critique or commentary welcome.

Since I'm on Linux, ELF works perfectly, and I already have ELF codegen that
produces Ahead-of-time compiled ELF's now, I just need to figure out how to
convert that to use the JIT engine instead, I presume.  I assume I would
need to produce an in-memory .so dynamically loaded library format file
then.  Does that sound right?

Lastly, could the JITDebugRegisterer.(cpp|h) functionality be made a part of
the DNB.h interface?

Thanks,
Jason


> On Wed, Mar 16, 2011 at 3:02 PM, Jason E. Aten <j.e.aten at gmail.com> wrote:
> > Thank you Reid, that makes alot of sense now.  Is there an API to the JIT
> > functionality?  If so,
> > could you point out where in the code base it lives, and if there are
> > examples of clients (how to
> > use it?)
> > Thanks!
> > Jason
> >
> > On Wed, Mar 16, 2011 at 1:58 PM, Reid Kleckner <reid.kleckner at gmail.com>
> > wrote:
> >>
> >> On Wed, Mar 16, 2011 at 2:52 PM, Jason E. Aten <j.e.aten at gmail.com>
> wrote:
> >> > Jim, thank you--that makes alot of sense. I hadn't thought through the
> >> > signal implications.  And re-reading Reid's post, he does make it
> clear
> >> > that
> >> > the JIT-code injection is somehow a part of an interprocess
> >> > communication.
> >> > The question then becomes, does the DNB.h protocol support the
> JIT-code
> >> > injection, or if not, could that be a part of it?
> >>
> >> Yup, it works similar to the way debuggers find out about dynamically
> >> loaded libraries.  There's a particular loader stub that gets called
> >> after every library load or unload.  Debuggers put a breakpoint on it
> >> to stop the inferior process and re-read the list of loaded libraries
> >> with remote memory examination routines, so there's your (hacky) IPC.
> >>
> >> Reid
> >
> >
> >
> > --
> > Jason E. Aten, Ph.D.
> >
> >
> >
>



-- 
Jason E. Aten, Ph.D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20110316/1607c1d5/attachment.html>