[Lldb-commits] [PATCH] Allow MachO JIT debugging

[Keno Fischer]

I have updated the patch. Sorry this took a while but I've had to think
about whether there are any better ways to do this. You may have seen my
thread of llvmdev. I'm a little frustrated with MachO at this point, but
after experimenting with the possible alternatives for a while I came back
to this. I replaced the arbitrary cutoff by a heuristic based on LLVMs
algorithm (i.e. it will always work for LLVM generated MachO files). I
think that is good enough for now. If there are more clients out there, and
they do something different, we can look at revising the heuristic. The
best thing to fix this would be to reserve a flag on the section that
indicates that the section has been runtime relocated, so if the people
behind MachO would be willing to consider that that'd be awesome. Otherwise
the heuristic works fine for now though. The other two concerns were fixed
as discussed.

I'm still a little disappointed that we probably won't be able to avoid
relocating the debug info on the MCJIT side (see the llvmdev thread I
started on the semantics of X86_64_RELOC_UNSIGNED). I guess the only thing
we could do is still apply the relocation but do it in place. Not great,
but probably worth it to avoid the extra copy of the debug info especially
since debug info can get pretty large.


On Thu, Jun 5, 2014 at 2:26 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> > On Jun 5, 2014, at 10:44 AM, Keno Fischer <kfischer at college.harvard.edu>
> wrote:
> >
> > I missed your question about macho file types. These are all MH_OBJECTs.
>
> Then you might be able to key off of that instead of always trying to read
> from the load commands.
>
> It would then be:
>
> if (process && m_header.filetype != llvm::MachO::MH_OBJECT)
> {
>     // Read symbol table from memory
> }
> else
> {
>     // read symbol table using load commands
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140613/8d182846/attachment.html>