[lldb-dev] JIT debugging and Windows

[Keno Fischer]

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 <andrew.macp at gmail.com>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 <
> kfischer at college.harvard.edu> 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 <
>> andrew.macp at gmail.com> 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 <
>>> kfischer at college.harvard.edu> 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 <
>>>> andrew.macp at gmail.com> 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 <
>>>>> kfischer at college.harvard.edu> 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
>>>>>> lldb-dev at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131229/de4e056a/attachment.html>