llvm-project/clang/test/Driver/pic.c

264 lines
14 KiB
C
Raw Normal View History

Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// Test the driver's control over the PIC behavior. These consist of tests of
// the relocation model flags and the pic level flags passed to CC1.
//
// CHECK-NO-PIC: "-mrelocation-model" "static"
// CHECK-NO-PIC-NOT: "-pic-level"
// CHECK-NO-PIC-NOT: "-pie-level"
//
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// CHECK-PIC1: "-mrelocation-model" "pic"
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// CHECK-PIC1: "-pic-level" "1"
// CHECK-PIC1-NOT: "-pie-level"
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
//
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// CHECK-PIC2: "-mrelocation-model" "pic"
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// CHECK-PIC2: "-pic-level" "2"
// CHECK-PIC2-NOT: "-pie-level"
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
//
// CHECK-STATIC: "-static"
// CHECK-NO-STATIC-NOT: "-static"
//
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// CHECK-PIE1: "-mrelocation-model" "pic"
// CHECK-PIE1: "-pic-level" "1"
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// CHECK-PIE1: "-pie-level" "1"
//
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// CHECK-PIE2: "-mrelocation-model" "pic"
// CHECK-PIE2: "-pic-level" "2"
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// CHECK-PIE2: "-pie-level" "2"
//
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// CHECK-PIE-LD: "{{.*}}ld{{(.exe)?}}"
// CHECK-PIE-LD: "-pie"
// CHECK-PIE-LD: "Scrt1.o" "crti.o" "crtbeginS.o"
// CHECK-PIE-LD: "crtendS.o" "crtn.o"
//
// CHECK-NOPIE-LD: "-nopie"
//
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// CHECK-DYNAMIC-NO-PIC-32: "-mrelocation-model" "dynamic-no-pic"
// CHECK-DYNAMIC-NO-PIC-32-NOT: "-pic-level"
// CHECK-DYNAMIC-NO-PIC-32-NOT: "-pie-level"
//
// CHECK-DYNAMIC-NO-PIC-64: "-mrelocation-model" "dynamic-no-pic"
// CHECK-DYNAMIC-NO-PIC-64: "-pic-level" "2"
// CHECK-DYNAMIC-NO-PIC-64-NOT: "-pie-level"
//
// CHECK-NON-DARWIN-DYNAMIC-NO-PIC: error: unsupported option '-mdynamic-no-pic' for target 'i386-unknown-unknown'
//
// CHECK-NO-PIE-NOT: "-pie"
//
// CHECK-NO-UNUSED-ARG-NOT: argument unused during compilation
//
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fpic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC1
// RUN: %clang -c %s -target i386-unknown-unknown -fPIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target i386-unknown-unknown -fpie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE1
// RUN: %clang -c %s -target i386-unknown-unknown -fPIE -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE2
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
//
// Check that PIC and PIE flags obey last-match-wins. If the last flag is
// a no-* variant, regardless of which variant or which flags precede it, we
// get no PIC.
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -fpic -fno-pic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -fPIC -fno-pic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fpie -fno-pic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fPIE -fno-pic -### 2>&1 \
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fpic -fno-PIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -fPIC -fno-PIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fpie -fno-PIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fPIE -fno-PIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fpic -fno-pie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fPIC -fno-pie -### 2>&1 \
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fpie -fno-pie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -fPIE -fno-pie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fpic -fno-PIE -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fPIC -fno-PIE -### 2>&1 \
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-unknown-unknown -fpie -fno-PIE -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -fPIE -fno-PIE -### 2>&1 \
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
//
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// Last-match-wins where both pic and pie are specified.
// RUN: %clang -c %s -target i386-unknown-unknown -fpie -fpic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC1
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -fPIE -fpic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC1
// RUN: %clang -c %s -target i386-unknown-unknown -fpie -fPIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -fPIE -fPIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target i386-unknown-unknown -fpic -fpie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE1
// RUN: %clang -c %s -target i386-unknown-unknown -fPIC -fpie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE1
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -fpic -fPIE -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE2
// RUN: %clang -c %s -target i386-unknown-unknown -fPIC -fPIE -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE2
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
//
// Last-match-wins when selecting level 1 vs. level 2.
// RUN: %clang -c %s -target i386-unknown-unknown -fpic -fPIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -fPIC -fpic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC1
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -fpic -fPIE -fpie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE1
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -fpie -fPIC -fPIE -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE2
//
// Make sure -pie is passed to along to ld and that the right *crt* files
// are linked in.
// RUN: %clang %s -target i386-unknown-freebsd -fPIE -pie -### \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/basic_freebsd_tree 2>&1 \
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: | FileCheck %s --check-prefix=CHECK-PIE-LD
// RUN: %clang %s -target i386-linux-gnu -fPIE -pie -### \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: | FileCheck %s --check-prefix=CHECK-PIE-LD
// RUN: %clang %s -target i386-linux-gnu -fPIC -pie -### \
// RUN: --gcc-toolchain="" \
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE-LD
//
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// Disregard any of the PIC-specific flags if we have a trump-card flag.
// RUN: %clang -c %s -target i386-unknown-unknown -mkernel -fPIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// The -static argument *doesn't* override PIC: -static only affects
// linking, and -fPIC only affects code generation.
Teach Clang about PIE compilations. This is the first step of PR12380. First, this patch cleans up the parsing of the PIC and PIE family of options in the driver. The existing logic failed to claim arguments all over the place resulting in kludges that marked the options as unused. Instead actually walk all of the arguments and claim them properly. We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the last one on the commandline. Previously there were lots of ordering bugs that could creep in due to the nature of the parsing. Let me know if folks would like weird things such as "-fPIE -fno-pic" to turn on PIE, but disable full PIC. This doesn't make any sense to me, but we could in theory support it. Options that seem to have intentional "trump" status (-static, -mkernel, etc) continue to do so and are commented as such. Next, a -pie-level flag is threaded into the frontend, rigged to a language option, and handled preprocessor, setting up the appropriate defines. We'll now have the correct defines when compiling with -fpie. The one place outside of the preprocessor that was inspecting the PIC level (as opposed to the relocation model, which is set and handled separately, yay!) is in the GNU ObjC runtime. I changed it to exactly preserve existing behavior. If folks want to change its behavior in the face of PIE, they can do that in a separate patch. Essentially the only functionality changed here is the preprocessor defines and bug-fixes to the argument management. Tests have been updated and extended to test all of this a bit more thoroughly. llvm-svn: 154291
2012-04-09 00:40:35 +08:00
// RUN: %clang -c %s -target i386-unknown-unknown -static -fPIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang %s -target i386-linux-gnu -static -fPIC -### \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-STATIC
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
//
// On Linux, disregard -pie if we have -shared.
// RUN: %clang %s -target i386-unknown-linux -shared -pie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIE
//
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// Darwin is a beautiful and unique snowflake when it comes to these flags.
// When targeting a 32-bit darwin system, only level 2 is supported. On 64-bit
// targets, there is simply nothing you can do, there is no PIE, there is only
// PIC when it comes to compilation.
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-apple-darwin -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target i386-apple-darwin -fpic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target i386-apple-darwin -fPIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target i386-apple-darwin -fpie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE2
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-apple-darwin -fPIE -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE2
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target i386-apple-darwin -fno-PIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-apple-darwin -fno-PIE -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target i386-apple-darwin -fno-PIC -fpic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target i386-apple-darwin -fno-PIC -fPIE -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE2
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
// RUN: %clang -c %s -target x86_64-apple-darwin -fno-PIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target x86_64-apple-darwin -fno-PIE -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target x86_64-apple-darwin -fpic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target x86_64-apple-darwin -fPIE -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target x86_64-apple-darwin -fPIC -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-UNUSED-ARG
Completely re-work how the Clang driver interprets PIC and PIE options. There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
2012-11-19 11:52:03 +08:00
//
// Darwin gets even more special with '-mdynamic-no-pic'. This flag is only
// valid on Darwin, and it's behavior is very strange but needs to remain
// consistent for compatibility.
// RUN: %clang -c %s -target i386-unknown-unknown -mdynamic-no-pic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NON-DARWIN-DYNAMIC-NO-PIC
// RUN: %clang -c %s -target i386-apple-darwin -mdynamic-no-pic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-DYNAMIC-NO-PIC-32
// RUN: %clang -c %s -target i386-apple-darwin -mdynamic-no-pic -fno-pic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-DYNAMIC-NO-PIC-32
// RUN: %clang -c %s -target i386-apple-darwin -mdynamic-no-pic -fpie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-DYNAMIC-NO-PIC-32
// RUN: %clang -c %s -target x86_64-apple-darwin -mdynamic-no-pic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-DYNAMIC-NO-PIC-64
// RUN: %clang -c %s -target x86_64-apple-darwin -mdynamic-no-pic -fno-pic -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-DYNAMIC-NO-PIC-64
// RUN: %clang -c %s -target x86_64-apple-darwin -mdynamic-no-pic -fpie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-DYNAMIC-NO-PIC-64
//
// Checks for ARM+Apple+IOS including -fapple-kext, -mkernel, and iphoneos
// version boundaries.
// RUN: %clang -c %s -target armv7-apple-ios -fapple-kext -miphoneos-version-min=6.0.0 -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target armv7-apple-ios -mkernel -miphoneos-version-min=6.0.0 -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target arm64-apple-ios -mkernel -miphoneos-version-min=7.0.0 -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -x assembler -c %s -target arm64-apple-ios -mkernel -miphoneos-version-min=7.0.0 -no-integrated-as -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-STATIC
// RUN: %clang -c %s -target armv7k-apple-watchos -fapple-kext -mwatchos-version-min=1.0.0 -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target armv7-apple-ios -fapple-kext -miphoneos-version-min=5.0.0 -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target armv7-apple-ios -fapple-kext -miphoneos-version-min=6.0.0 -static -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target armv7-apple-unknown-macho -static -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
//
// On OpenBSD, PIE is enabled by default, but can be disabled.
// RUN: %clang -c %s -target amd64-pc-openbsd -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE1
// RUN: %clang -c %s -target i386-pc-openbsd -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE1
// RUN: %clang -c %s -target mips64-unknown-openbsd -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE1
// RUN: %clang -c %s -target mips64el-unknown-openbsd -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE1
// RUN: %clang -c %s -target powerpc-unknown-openbsd -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE2
// RUN: %clang -c %s -target sparc-unknown-openbsd -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE2
// RUN: %clang -c %s -target sparc64-unknown-openbsd -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIE2
// RUN: %clang -c %s -target i386-pc-openbsd -fno-pie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
//
// On OpenBSD, -nopie needs to be passed through to the linker.
// RUN: %clang %s -target i386-pc-openbsd -nopie -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NOPIE-LD
//
// On Android PIC is enabled by default
// RUN: %clang -c %s -target i686-linux-android -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target arm-linux-androideabi -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC1
// RUN: %clang -c %s -target mipsel-linux-android -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC1
// RUN: %clang -c %s -target aarch64-linux-android -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC1
// RUN: %clang -c %s -target arm64-linux-android -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC1
//
// On Windows-X64 PIC is enabled by default
// RUN: %clang -c %s -target x86_64-pc-windows-msvc18.0.0 -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
// RUN: %clang -c %s -target x86_64-pc-windows-gnu -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-PIC2