[LLVMdev] Supporting multiple PIC/PLT formats per architecture

Hal Finkel hfinkel at anl.gov
Tue Aug 19 16:44:30 PDT 2014


----- Original Message -----
> From: "Justin Hibbits" <chmeeedalf at gmail.com>
> To: llvmdev at cs.uiuc.edu
> Sent: Saturday, August 16, 2014 2:26:25 PM
> Subject: [LLVMdev] Supporting multiple PIC/PLT formats per architecture
> 
> Hi,
> 
> PowerPC, and SPARC, supports both -fpic and -fPIC with gcc, and it
> may
> make a difference on other architectures as well. However, llvm
> currently does not distinguish between them (see
> http://llvm.org/bugs/show_bug.cgi?id=20385).  I currently have both
> models working, but are mutually exclusive, since I haven't thought
> of
> a good way of supporting them.  clang has some level of support, with
> the '-pic-level' flag, but it's not documented, and I'm not clear if
> it
> even passes this information down to llvm.
> 
> PowerPC makes this even more interesting, because it also supports a
> 'secure PLT' mode, which makes the PLT read-only.  I haven't
> verified,
> but it likely also works on both pic levels (-fpic, -fPIC), so there
> needs to be some way of supporting this as well.
> 
> One proposal I have is to have a '-pic-level' and '-secure-plt'
> arguments for llc, supported by two extra flags in the class
> MCCodeGenInfo, PICLevel, and IsSecurePLT, accessible through
> accessors
> as the current flags are handled.  This way, existing code would
> behave
> as normal, and these new capabilities could be handled seamlessly.
> 
> Comments?

Passing the -fpic vs -fPIC distinction from Clang into the backends is certainly something we should do. Although unfortunately named, the two models are different, and we should allow backends to correctly implement both.

 -Hal

> 
> - Justin
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list