I've gotten pretty far, Code is here: https://github.com/loladiro/lldb It's interacting correctly with the debug interface and I've got it loading the object file from memory correctly for MachO/DWARF (working on ELF right now). Currently not much use as it doesn't seem to be looking at the debug information that were just added (I can see them via `image dump sections` and I can set breakpoints correctly though, so that's a plus). For DWARF, there's a few changes for upstream LLVM needed. I'll put them up if anybody's interested, otherwise, I'll just keep chugging along and wait until I have more complete patch.
- Keno On Sat, Dec 28, 2013 at 1:07 PM, Andrew MacPherson <[email protected]>wrote: > Hi Keno, > > I noticed the same thing and agree that the JIT loader doesn't perfectly > fit as a DynamicLoader, the suggestion from a couple of years back on the > list was to make the Process -> DynamicLoader relationship 1:n but I prefer > your suggestion of adding a new plugin type (JITLoader). Right now there > would only be one JITLoader type for the GDB interface. > > The patch could probably be fixed up as-is as a first step (leaving the > JIT loading bits as a growth on the DynamicLoaderPOSIXDYLD) and we could > move it out into its own plugin type once that's working. I should have > time this coming week to get this working but if you'll also have time then > I'm happy to leave it with you. > > Cheers, > Andrew > > > On Sat, Dec 28, 2013 at 9:37 AM, Keno Fischer < > [email protected]> wrote: > >> I've started looking into this and it's actually not that difficult to do >> (the JIT part at least). I think the most difficult thing is >> figuring out where to put the functionality. The way I see it, the JIT >> interface is almost a DynamicLoader, with the difference >> that asking it about things like whether or not loading a dynamic library >> is safe doesn't make much sense. Another problem >> is that currently there's a 1:1 relationship between Processes and >> DynamicLoaders. Perhaps a new class of Plugins >> (JITLoader?) could be added with a 1:n relationship to processes. Some of >> the interface (I'm thinking >> DidLaunch,DidAttach,Get/SetStopWhenImagesChange) could be pulled out >> into an abstract base class. Does that make >> sense. I'd be happy to implement this once we decide on the design. >> >> Keno >> >> >> On Wed, Dec 25, 2013 at 10:30 AM, Andrew MacPherson < >> [email protected]> wrote: >> >>> Looks great, thanks Keno. I'll look into this next week and keep you >>> posted. >>> >>> Cheers, >>> Andrew >>> >>> >>> On Tue, Dec 24, 2013 at 1:19 PM, Keno Fischer < >>> [email protected]> wrote: >>> >>>> I have this (as I said, I haven't tried it). It seems to be a different >>>> patch. >>>> >>>> >>>> On Tue, Dec 24, 2013 at 11:17 AM, Andrew MacPherson < >>>> [email protected]> wrote: >>>> >>>>> Hi Keno, >>>>> >>>>> I found this old patch that hooks into the GDB JIT registration >>>>> mechanism which we were planning to use as a starting point: >>>>> >>>>> http://lists.cs.uiuc.edu/pipermail/lldb-dev/2010-December/000314.html >>>>> >>>>> If you have anything else we'd love to take a look! >>>>> >>>>> Cheers, >>>>> Andrew >>>>> >>>>> >>>>> On Tue, Dec 24, 2013 at 8:34 AM, Keno Fischer < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Andrew, >>>>>> >>>>>> I'm also one of the Julia core developers and the guy currently >>>>>> working on >>>>>> debugging support. I was given a patch to add MCJIT debugging support >>>>>> to LLDB with the disclaimer that it probably doesn't work. I haven't >>>>>> tried it >>>>>> yet, so I can't say how close it is, but it's probably at least a >>>>>> starting point. >>>>>> >>>>>> I'd be happy to coordinate any efforts. >>>>>> >>>>>> - Keno >>>>>> >>>>>> _______________________________________________ >>>>>> lldb-dev mailing list >>>>>> [email protected] >>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
