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

Keno Fischer kfischer at college.harvard.edu
Thu Jun 5 09:47:54 PDT 2014


> - What is updateSectionLoadAddress(...) doing when it checks "if
(section_sp->GetFileAddress() > 0x100000)"?

LLVM allocates sections with relocations outside of the actual symbol file
and then updates the section vmaddr accordingly. What this code does is
basically traverse through the section tree and for every leaf section
adjust the load address accordingly. The only problem is that LLVm doesn't
actually relocate all sections, so we have to have some kind of check to
determine whether the section was relocated or not. The condition in there
right now is a stop gap and I'd like to come up with something more
reasonable (I meant to ask about that in the initial review). I think some
sort of comparison to the file size would be appropriate, but I don't know
enough about Mach O object files to know about the relation of vmaddr and
file offset. Any ideas?

> - Why are we preloading everything with the code: ...

Yes, you're right, that was for debugging and slipped past my cleanup.

> - Your fix to ObjectFileMachO.cpp is not correct...

The code in if (process) doesn't do anything if we don't have a
linkedit_section_sp. Maybe we need to duplicate that code in an else block
for linkedit_section_sp ...

Thank you for your comments. I'm learning as I'm going here.

Keno



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

> Can you explain a few things?:
>
> - What is updateSectionLoadAddress(...) doing when it checks "if
> (section_sp->GetFileAddress() > 0x100000)"?
> - Why are we preloading everything with the code:
>
>                  // load the symbol table right away
>                 module_sp->GetObjectFile()->GetSymtab();
>
>                 module_sp->GetSymbolVendor()->GetNumCompileUnits();
>                 module_sp->GetSymbolVendor()->GetCompileUnitAtIndex(0);
>                 module_sp->ParseAllDebugSymbols();
>
> This seems like we should just let it load things lazily. Parsing all
> debug symbols is not advised, it should be allowed to lazily parse the
> DWARF as it needs to.
>
> - Your fix to ObjectFileMachO.cpp is not correct. If we have a process,
> then we load the symbol table from memory (the code in the "if (process)"),
> else we load it from the load commands (in the "else") and from the file
> itself. We don't want to always load the symbol table from the load
> commands as the symtab_load_command.symoff and symtab_load_command.stroff
> are not correct when a mach-o file is being read from memory.
>
>
>
> > On Jun 3, 2014, at 9:46 AM, Keno Fischer <kfischer at college.harvard.edu>
> wrote:
> >
> > This is the LLDB side of http://reviews.llvm.org/D4005
> >
> > http://reviews.llvm.org/D4006
> >
> > Files:
> >  lib/Makefile
> >  source/Core/Section.cpp
> >  source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
> >  source/Plugins/Makefile
> >  source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
> > <D4006.10055.patch>_______________________________________________
> > lldb-commits mailing list
> > lldb-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140605/79aa3bbd/attachment.html>


More information about the lldb-commits mailing list