According to Android ABI, we have to link with
libdl.so, if we are linking with non-static libgcc.
Besides, this also fixes MIPS link error of
undefined references to `_Unwind_Find_FDE' and
`dl_iterate_phdr'.
llvm-svn: 168310
The dynamic linker of Android does not support .ctors/.dtors.
We should emit .init_array and .fini_array regardless the
gcc version.
NOTE: This patch does not affect the ARM backend, because
it is required to generate .init_array and .fini_array
for program targeting ARM AAPCS and AEABI.
llvm-svn: 168309
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
This was causing different behavior when using -x objective-c++-cpp-output as
compared to -x objc++-cpp-output. Specifically, the driver was not adding the
-fcxx-exceptions flag in the latter case.
rdar://12680312
llvm-svn: 168212
to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031
llvm-svn: 168063
- Separately check if -fPIE was specified in the command line and define both __PIC__ and __PIE__ when -fPIE is used. We need to check this separately because -fPIE will infer -fPIC even if its not explicitly used.
- Fixed existing tests.
- Added new tests for cases where both -fPIC and -fPIE is used.
Author: Tareq A. Siraj <tareq.a.siraj@intel.com>
Fixes: PR13221
Review: http://llvm-reviews.chandlerc.com/D94
llvm-svn: 167846
LTO doesn't generate correct accelerator tables. This is due to the general lack
correct of debug info for LTO. Disable it when using LTO.
<rdar://problem/12401423>
llvm-svn: 167799
-fno-address-sanitizer, -fthread-sanitizer, -fno-thread-sanitizer, and
-fcatch-undefined-behavior as deprecated: produce a warning if they are used
pointing to the corresponding -fsanitize= option. In passing add the missing
'-' to some diagnostics.
llvm-svn: 167429
checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.
llvm-svn: 167413
-fno-sanitize=<sanitizers> argument to driver. These allow ASan, TSan, and the
various UBSan checks to be enabled and disabled separately. Right now, the
different modes can't be combined, but the intention is that combining UBSan
and the other sanitizers will be permitted in the near future.
Currently, the UBSan checks will all be enabled if any of them is; that will be
fixed by the next patch.
llvm-svn: 167411
diagnostics script.
This addresses the FIXME pertaining to quoted arguments. We also delineate
between those flags that have an argument (e.g., -D macro, -MF file) and
those that do not (e.g., -M, -MM, -MG). Finally, we add the -dwarf-debug-flags
to the list of flags to be removed.
rdar://12329974
llvm-svn: 167152
is not a directory, Driver::GetProgramPath() routine does not try to append
the program name as a "path component" to it. It just joins the "prefix" with
the program name and checks the resulting path existence.
The patch reviewed by Rafael Espindola.
llvm-svn: 167114
later, '-L <dir>' is allowed, but rewrite these in the driver as '-L<dir>' to
maintain backward compatibility. The same is true for the -I option.
rdar://12366753
llvm-svn: 167054
we had the -ccc-clang-cxx and -ccc-no-clang-cxx options to force them
on or off for testing.
Clang c++ support is now production quality and these options are dead.
llvm-svn: 166986
Each option has a set of prefixes. When matching an argument such as
-funroll-loops. First the leading - is removed as it is a prefix. Then
a lower_bound search for "funroll-loops" is done against the option table by
option name. From there each option prefix + option name combination is tested
against the argument.
This allows us to support Microsoft style options where both / and - are valid
prefixes. It also simplifies the cases we already have where options come in
both - and -- forms. Almost every option for gnu-ld happens to have this form.
llvm-svn: 166444
- This is an assumption that is currently hardwired into the backend, we need
to do this in order for the frontend and backend to agree.
llvm-svn: 166428
Joey Gouly