[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