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

Kaylor, Andrew andrew.kaylor at intel.com
Tue Feb 19 12:35:01 PST 2013

That’s definitely a good point.  I’ll revise this to make a run-time check.


From: Filipe Cabecinhas [mailto:filcab at gmail.com]
Sent: Tuesday, February 19, 2013 12:31 PM
To: Kaylor, Andrew
Cc: lldb-commits at cs.uiuc.edu
Subject: Re: [Lldb-commits] [Review request] Linux code generation option change plus relocation handling fix

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?




On Tue, Feb 19, 2013 at 11:53 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto: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.


lldb-commits mailing list
lldb-commits at cs.uiuc.edu<mailto:lldb-commits at cs.uiuc.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20130219/fc677b67/attachment.html>

More information about the lldb-commits mailing list