[Lldb-commits] [Review request] Linux code generation option change plus relocation handling fix

[Filipe Cabecinhas]

Shouldn't the relocation model be set taking into account the target, and
not lldb itself?
Since Mac OS X has the debugserver, you could be on a Linux host remotely
debugging a Mac OS X program. In that case, wouldn't you want to stick to
PIC?

Thanks,

  Filipe

  F


On Tue, Feb 19, 2013 at 11:53 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote:

>  In testing LLDB with 32-bit executables on 64-bit Linux, we came across
> some problems with the expression evaluation (among other things).  It
> turns out that in spite of LLDB’s efforts to avoid relocations by replacing
> external calls with calls to addresses, there were still some relocations
> being generated.  In particular, the absolute address-based function calls
> in the expression IR were being generated as PC-relative calls in x86
> machine code.  There was also a relocation based on the
> _GLOBAL_OFFSET_TABLE_ symbol, though the generated image contained no .got
> section.****
>
> ** **
>
> Most of these issues were resolved by fixing problems in the MCJIT code
> (which I will be committing shortly).  However, there were a couple of
> changes necessary in LLDB.  First, and most significantly, I’m modifying
> LLDB to request ‘static’ code generation rather than ‘PIC’ on Linux,
> because the ELF-version of MCJIT’s RuntimeDyld component doesn’t currently
> handle PIC code correctly.  Second, I added a function call to get
> relocations to be properly applied before generated code is copied to the
> inferior.****
>
> ** **
>
> A patch for the LLDB changes is attached.  If there are no objections,
> I’ll commit it soon.  It just seemed best to float it out for review before
> proceeding to give people a chance to comment.****
>
> ** **
>
> Thanks,****
>
> Andy****
>
> _______________________________________________
> 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/20130219/79b1994c/attachment.html>