Commit Graph

162 Commits

Author SHA1 Message Date
Simon Atanasyan 68855fe3c9 [Mips] Add support for mips64el-linux-android triple.
llvm-svn: 200081
2014-01-25 16:04:08 +00:00
Alexey Bataev cf7ae30135 Improve x86 android support, add x86_64 android target
llvm-svn: 199875
2014-01-23 09:08:32 +00:00
Chandler Carruth 902efc61be Teach Clang to look in its installation libdir for libraries (such as
libc++) when the installation is within the system root.

This doesn't really help cross compiles much, but we don't (currently)
have a great story around libc++, cross compiles, and who is responsible
for building and/or installing the libraries. However, it handles the
very common case of non-cross builds in a way entirely consistent with
GCC, so I'm hopeful this won't really hose anyone.

This is the second patch that I think should be backported to 3.4 to
give folks an easy to checkout and install working Clang+libc++
toolchain.

llvm-svn: 199769
2014-01-21 22:49:05 +00:00
Alexey Bataev 75db8c386d Rename target i386-linux-android to i686-linux-android
llvm-svn: 199073
2014-01-13 03:49:38 +00:00
Jakob Stoklund Olesen 73cb84c271 Use the right dynamic linker for SPARC Linux executables.
llvm-svn: 198923
2014-01-10 08:18:34 +00:00
Jakob Stoklund Olesen 91a8e03af0 Give the linker the right ELF type for SPARC targets.
llvm-svn: 198912
2014-01-10 03:51:33 +00:00
Chandler Carruth da797048d9 Teach the driver to not try to use 'lib32' multilib spellings on ARM
which doesn't use that multilib. As a consequence, fix Clang's support
for cross compiling environments that were relying on this quirk to
ensure the correct library search path ordering.

This also re-instates the new test cases from Rafael's r193528 for
cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the
existing test cases (they were no longer needed).

This solution was the result of a lot of IRC debugging and trying to
understand *exactly* what quirk was being relied upon. It took some time
for me to figure out that it was the use of 'lib32' is a multilib that
was throwing a wrench in the works.

In case you are thinking that its silly to use a multilib of 'lib' at
all, entertainingly, GCC does so as well (you can see it with the
.../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of
search paths (multilib followed by non-multilib) has observable (if
dubious) consequences. =/ Yuck.

llvm-svn: 193601
2013-10-29 10:27:30 +00:00
Rafael Espindola a839855b56 Revert "Support cross linking to arm on ubuntu."
This reverts commit r193528 (and fixes).

It broke Chandler's setup.

llvm-svn: 193554
2013-10-28 23:14:34 +00:00
Rafael Espindola 2b5e65d95b More windows path handling.
llvm-svn: 193533
2013-10-28 19:40:25 +00:00
Rafael Espindola c6329b283e Relax test to pass with windows paths.
llvm-svn: 193532
2013-10-28 19:19:29 +00:00
Rafael Espindola cdd2c0044d Support cross linking to arm on ubuntu.
With this patch we correctly determine that ubuntu's ARM tree is not biarch
and use "lib" istead of "lib32".

Without this patch the search inside the arm tree for the crt files was failing
and we would end up trying to use the i686 ones in lib32.

llvm-svn: 193528
2013-10-28 18:52:30 +00:00
Rafael Espindola 0794a915a4 Don't check for -L options that gcc doesn't use.
GCC on fedora 18 ARM only uses 2 -L options. Clang prints two extra ones, but
we should not include them in the test as they are not required.

llvm-svn: 193430
2013-10-25 19:44:29 +00:00
Rafael Espindola 49ddb8675b Accept both / and \\ to fix the windows bots.
llvm-svn: 184790
2013-06-24 22:07:15 +00:00
Chandler Carruth 274b6f0c87 Update two options to my proposed syntax for user-facing driver options:
-gcc-toolchain foo  ->  --gcc-toolchain=foo
  -target foo         ->  --target=foo

I've added legacy aliases for the original spellings. I've updated the
canonical tests to check both spellings, and switched all of the
-gcc-toolchain usages elsewhere in the test suite to use the new one.
I've updated some of the usages of -target to the new syntax, but will
finish that in a separate entirely mechanical change once I'm sure this
won't get rolled back for some reason (It touches a *huge* number of RUN
lines in the test suite unsurprisingly).

A nice result is that the three most common flags I end up using when
doing cross compiles are all now consistent: --target=, --sysroot=, and
--gcc-toolchain=.

llvm-svn: 184408
2013-06-20 09:42:40 +00:00
Eric Christopher ac0217424c When we're compiling with -pg make sure to link with gcrt1.o on linux. Be
sure to do this always, this matches the behavior for the gcc driver.

Fixes PR16251.

Based on a patch by Qiao Yang.

llvm-svn: 183591
2013-06-07 23:25:01 +00:00
Rafael Espindola 50ba983d25 Add driver support for fedora 18 on ARM.
llvm-svn: 179484
2013-04-14 10:14:21 +00:00
Chandler Carruth 58d6eb6d03 Check for warnings in a bunch of the linker invocations, and add one
with both -static-libgcc and -static on the commandline.

Fix a warning in the latter case due to a backwards short circuiting ||
operator in the driver. No real functionality changed here, just allows
the driver to properly consume -static-libgcc when -static is also
specified.

llvm-svn: 176429
2013-03-04 02:07:55 +00:00
Chandler Carruth 4588e349b0 Beef up the testing of our 'ld' invocation on linux to cover static
linking. About to fix a bug here and there was no good test case.

llvm-svn: 176427
2013-03-04 01:27:49 +00:00
Logan Chien 48a353d339 Revert r169557. It seems that the test is too restricted
and will break the build on buildbot.

llvm-svn: 169562
2012-12-06 23:40:31 +00:00
Logan Chien 74aa8f1141 Add i686-linux-android for gcc toolchain detection.
* Look for i686-linux-android under <sysroot>/lib/gcc.

* This patch also slightly enhance the test suite for
  Android GCC toolchain detection.

llvm-svn: 169557
2012-12-06 22:59:37 +00:00
Logan Chien 3d3373ceb6 Add -ldl for non-static libgcc in Android.
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
2012-11-19 12:04:11 +00:00
Rafael Espindola 7df3501b49 Improve x86 android support:
* -Bsymbolic must be added for x86 as well.
* Default CPU name also set to 'core2' for x86 android.
Patch by Edwin Vane.

llvm-svn: 167307
2012-11-02 20:41:30 +00:00
Simon Atanasyan 2d1b1ad831 Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option.
The patch reviewed by Rafael Espindola.

llvm-svn: 166389
2012-10-21 11:44:57 +00:00
Rafael Espindola fc3fc0c936 The clang driver has a fairly fancy support for executing gcc instead of
clang itself. This dates back to clang's early days and while it looks like
some of it is still used (for kext for example), other parts are probably dead.

Remove the -ccc-clang-archs option and associated code. I don't think there
is any remaining setup where clang doesn't support an architecture but it can
expect an working gcc cross compiler to be available.

A nice side effect is that tests no longer need to differentiate architectures
that are included in production builds of clang and those that are not.

llvm-svn: 165545
2012-10-09 20:46:28 +00:00
Benjamin Kramer 058666a8d0 Driver: Link crtfastmath.o if it's available and -ffast-math is specified.
crtfastmath.o contains routines to set the floating point flags to a faster,
unsafe mode. Linking it in speeds up code dealing with denormals significantly
(PR14024).

For now this is only enabled on linux where I can test it and crtfastmath.o is
widely available. We may want to provide a similar file with compiler-rt
eventually and/or enable it on other platforms too.

llvm-svn: 165240
2012-10-04 19:42:20 +00:00
Simon Atanasyan 53fefd1f6a Implement Adnroid MIPS toolchain support:
1. Add mipsel-linux-android to the list of valid MIPS target triples.
2. Add <gcc install path>/mips-r2 to the list of toolchain specific path
   prefixes if target is mipsel-linux-android.

The patch reviewed by Logan Chien.

llvm-svn: 165131
2012-10-03 17:46:38 +00:00
Hal Finkel f358791e27 Add C/C++ header locations for the Freescale SDK.
The Freescale SDK is based on OpenEmbedded, and this might be useful
for other OpenEmbedded-based configurations as well.

With minor modifications, patch by Tobias von Koch!

llvm-svn: 164177
2012-09-18 22:25:07 +00:00
Simon Atanasyan d44138808f Do not use "lib32" directory to create a library/object files
paths when target is MIPS 32-bit.

The patch reviewed by Chandler Carruth.

llvm-svn: 163898
2012-09-14 11:27:24 +00:00
Evgeniy Stepanov c9cde48f3a Wrong crtbegin/crtend pair used for PIE on Android.
Android uses the same flavour of crt*.o for PIE and non-PIE executables, and a
different one for DSOs. GNU/Linux, on the other hand, uses one set of crt*.o
for non-PIE executables, and another for both PIE executables and DSOs.

llvm-svn: 163500
2012-09-10 10:30:12 +00:00
Evgeniy Stepanov 763671edeb Android standalone toolchain support.
This change adds detection of C++ headers and libraries paths when
building with the standalone toolchain from Android NDK. They are in a
slightly unusual place.

llvm-svn: 163109
2012-09-03 09:05:50 +00:00
Logan Chien c6fd820937 Rename ANDROIDEABI to Android.
Most of the code guarded with ANDROIDEABI are not
ARM-specific, and having no relation with arm-eabi.
Thus, it will be more natural to call this
environment "Android" instead of "ANDROIDEABI".

Note: We are not using ANDROID because several projects
are using "-DANDROID" as the conditional compilation
flag.

llvm-svn: 163088
2012-09-02 09:30:11 +00:00
Jiangning Liu 61b06cbcb4 Support ARM hard float (arm-linux-gnueabihf).
llvm-svn: 161038
2012-07-31 08:06:29 +00:00
Jiangning Liu eabbf92223 Fix dynamic object linker for ARM GNUEABIHF.
llvm-svn: 160958
2012-07-30 11:05:56 +00:00
Simon Atanasyan 9bb634df36 MIPS: Add support for 64-bit MIPS targets: mips64 / mips64el.
llvm-svn: 155656
2012-04-26 19:57:02 +00:00
Simon Atanasyan 2be62257a8 MIPS: Add tests to check the debian multiarch stuff for mips and mipsel targets.
llvm-svn: 155628
2012-04-26 08:35:58 +00:00
Evgeniy Stepanov 7786671b5a Clang driver support for linking on Android.
llvm-svn: 155541
2012-04-25 08:59:22 +00:00
Simon Atanasyan 1e1e2e2d9a MIPS: Provide a correct path to the dynamic linker when build for MIPS 64-bit targets.
llvm-svn: 154200
2012-04-06 20:14:27 +00:00
Chandler Carruth 69a125bf02 Fix using Clang as a cross compiler installed on a host machine and not
inside of a sysroot targeting a system+sysroot which is "similar" or
"compatible" with the host system. This shows up when trying to build
system images on largely compatible hardware as-if fully cross compiled.

The problem is that previously we *perfectly* mimiced GCC here, and it
turns out GCC has a bug that no one has really stumbled across. GCC will
try to look in thy system prefix ('/usr/local' f.ex.) into which it is
instaled to find libraries installed along side GCC that should be
preferred to the base system libraries ('/usr' f.ex.). This seems not
unreasonable, but it has a very unfortunate consequence when combined
with a '--sysroot' which does *not* contain the GCC installation we're
using to complete the toolchain. That results in some of the host
system's library directories being searched during the link.

Now, it so happens that most folks doing stuff like this use
'--with-sysroot' and '--disable-multilib' when configuring GCC. Even
better, they're usually not cross-compiling to a target that is similar
to the host. As a result, searching the host for libraries doesn't
really matter -- most of the time weird directories get appended that
don't exist (no arm triple lib directory, etc). Even if you're
cross-compiling from 32-bit to 64-bit x86 or vice-versa, disabling
multilib makes it less likely that you'll actually find viable libraries
on the host. But that's just luck. We shouldn't rely on this, and this
patch disables looking in the system prefix containing the GCC
installation if that system prefix is *outside* of the sysroot. For
empty sysroots, this has no effect. Similarly, when using the GCC
*inside* of the sysroot, we still track wherever it is installed within
the sysroot and look there for libraries. But now we can use a cross
compiler GCC installation outside the system root, and only look for the
crtbegin.o in the GCC installation, and look for all the other libraries
inside the system root.

This should fix PR12478, allowing Clang to be used when building
a ChromiumOS image without polluting the image with libraries from the
host system.

llvm-svn: 154176
2012-04-06 16:32:06 +00:00
Chandler Carruth af3c2090b4 Add support for PPC and PPC64 multiarch toolchains on Debain.
Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added
64-bit support. I just added one other place where powerpc64-linux-gnu
was missing (we only had powerpc64-unknown-linux-gnu).

I've also added a tree to test out the debian multiarch stuff. I don't
use debian regularly, so I'm not certain this is entirely accurate. If
anyone wants to check it against a debian system and fix any
inaccuracies, fire away. This way at least folks can see how this is
*supposed* to be tested.

It'd be particularly good to get the Debian MIPS toolchains tested in
this way.

llvm-svn: 151482
2012-02-26 09:03:21 +00:00
Sebastian Pop 422377cfd3 rename -ccc-host-triple into -target
llvm-svn: 148582
2012-01-20 22:01:23 +00:00
Eli Friedman d749c6bf2e Revert r148138; it's causing test failures.
llvm-svn: 148141
2012-01-13 21:33:06 +00:00
Sebastian Pop 9a8d528ddf rename -ccc-host-triple into -target
llvm-svn: 148138
2012-01-13 20:37:02 +00:00
Chandler Carruth 7cf80e3850 Teach the link-step test to verify that we don't pass bad --hash-style
flags on MIPS paltforms.

llvm-svn: 146837
2011-12-17 21:57:25 +00:00
Hal Finkel 6b89a10b45 add tree test for suse on ppc64 (r146142)
llvm-svn: 146176
2011-12-08 20:36:19 +00:00
Chandler Carruth 6e46ca2c10 Fix an issue that Duncan discovered on a specific (no longer current)
version of Ubuntu. It has a very broken multiarch configuration, and so
we need special logic to handle it correctly. Fixing and testing this
uncovered a few other trivial issues with the logic that are fixed as
well.

I added tests to cover this as it is hard to notice if you install
recent versions of the OS.

llvm-svn: 144165
2011-11-09 03:46:20 +00:00
Chandler Carruth bff1e8d53d Enhance the GCC version parsing and comparison logic to handle some more
edge cases and have better behavior. Specifically, we should actually
prefer the general '4.6' version string over the '4.6.1' string, as
'4.6.2' should be able to replace it without breaking rpaths or any
other place that these paths have been embedded. Debian-based
distributions are already using a path structure with symlinks to
achieve in-place upgrades for patch versions. Now our parsing reflects
this and we select the shorter paths instead of the longer paths.

A separate issue was that we would not parse a leading patch version
number even in the presence of a suffix. The above change makes this
more problematic as it would cause a suffix being added to make us treat
the entire thing as patch-version-agnostic, which it isn't. This changes
the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that
the latter has *some* patch number information. Currently, we always
bias toward the shorter and more canonical version strings. If it
becomes important we can add more Debian like rules to produce sequences
such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5',
but I'm very doubtful this will ever matter or be desirable.

I've made the tests for this logic a bit more interesting, and added
some specific tests for logic that is now different.

llvm-svn: 143841
2011-11-05 23:24:30 +00:00
Chandler Carruth e276b3662b Use the InstalledDir correctly, and test it correctly as well. =/ Should
have noticed this previously, sorry.

llvm-svn: 141167
2011-10-05 06:38:03 +00:00
Chandler Carruth cf59bc5939 Teach Clang to cope with GCC installations that have unusual patch
"versions". Currently, these are just dropped on the floor, A concrete
version number will always win out.

llvm-svn: 141159
2011-10-05 03:09:51 +00:00
Chandler Carruth f7e0ecb65d Implement the feature I was originally driving toward when I started
this saga. Teach the driver to detect a GCC installed along side Clang
using the existing InstalledDir support in the Clang driver. This makes
a lot of Clang's behavior more automatic when it is installed along side
GCC.

Also include the first test cases (more to come, honest) which test both
the install directory behavior, and the version sorting behavior to show
that we're actually searching for the best candidate GCC installation
now.

llvm-svn: 141145
2011-10-05 01:01:57 +00:00
Chandler Carruth adf23a400d Test a multilib setup on a 64-bit host. This is the far more common
configuration, although the test still stubs out more directories than
are necessary or common in order to exercise all of the lookup paths
observed with upstream GCC.

This finishes testing the distribution-independent and
GCC-installation-independent parts of the library path search logic.
More testing is still needed for the triple detection, GCC-installation
detection, and handling distributions with unusual configurations.

llvm-svn: 141000
2011-10-03 09:08:26 +00:00
Chandler Carruth 2356b2c307 Enable generic multilib support on 32bit hosts. Previously this was only
enabled for debian hosts, which is quite odd. I think all restriction on
when Clang attempts to use a multilib installation should go away. Clang
is fundamentally a cross compiler. It behaves more like GCC when built
as a cross compiler, and so it should just use multilib installs when
they are present on the system. However, there is a very specific
exemption for Exherbo, which I can't test on, so I'm leaving that in
place.

With this, check in a generic test tree for multilib on a 32-bit host.
This stubs out many directories that most distributions don't use but
that uptsream GCC supports. This is intended to be an agnostic test that
the driver behaves properly compared with the GCC driver it aims for
compatibility with.

Also, fix a bug in the driver that this testing exposed (see!) where it
was incorrectly testing the target architecture rather than the host
architecture.

If anyone is having trouble with the tree-structure stubs I'm creating
to test this, let me know and I can revisit the design. I chose this
over (for example) a tar-ball in order to make tests run faster at the
small, hopefully amortized VCS cost.

llvm-svn: 140999
2011-10-03 09:00:50 +00:00
Chandler Carruth 35cd702e73 Relax an assertion here a bit. This doesn't really matter, as we won't
include *any* path on crtbegin.o unless we actually find such a file via
one of the search paths. We still strictly check the search paths right
after this, so we'll catch any issues there.

The reason for this is that the driver does some normalization of the
path on the actual object file, and this changes the textual format of
the string on Windows. It no longer matches the textual format of the
sysroot flag.

llvm-svn: 140998
2011-10-03 08:16:09 +00:00
Chandler Carruth 2c5e91e2e5 Test that we include a GCC-triple-prefixed tree. While I don't know of
any distros that use this, building a multilib GCC from mainline will
install linker scripts here.

llvm-svn: 140996
2011-10-03 08:09:02 +00:00
Chandler Carruth 5fdc7cba2a Teach the logic for locating an installed GCC about the system root.
This requires fixing a latent bug -- if we used the default host triple
instead of an autodetected triple to locate GCC's installation, we
didn't go back and fix the GCC triple. Correct that with a pile of
hacks. This entire routine needs a major refactoring which I'm saving
for a subsequent commit. Essentially, the detection of the GCC triple
should be hoisted into the same routine as we locate the GCC
installation: the first is intrinsically tied to the latter. Then the
routine will just return the triple and base directory.

Also start to bring the rest of the library search path logic under
test, including locating crtbegin.o. Still need to test the multilib and
other behaviors, but there are also bugs in the way of that.

llvm-svn: 140995
2011-10-03 08:02:58 +00:00
Chandler Carruth 2a649c7a42 Add initial support for applying the sysroot to library search paths.
This is still very much a WIP, but sysroot was completely broken before
this so we are moving closer to correctness.

The crux of this is that 'ld' (on Linux, the only place I'm touching
here) doesn't apply the sysroot to any flags given to it. Instead, the
driver must translate all the paths it adds to the link step with the
system root. This is easily observed by building a GCC that supports
sysroot, and checking its driver output.

This patch just fixes the non-multilib library search paths. We should
also use this in many other places, but first things first.

This also allows us to make the Linux 'ld' test independent of the host
system. This in turn will allow me to check in test tree configurations
based on various different distro's configuration. Again, WIP.

llvm-svn: 140990
2011-10-03 06:41:08 +00:00
Chandler Carruth 413e5ac2a5 Rework the selection of builtin library search paths on Linux to
precisely match the pattern and logic used by the GCC driver on Linux as
of a recent SVN checkout.

This happens to follow a *much* more principled approach. There is
a strict hierarchy of paths examined, first with multilib-suffixing,
second without such suffixing. Any and all of these directories which
exist will be added to the library search path when using GCC.

There were many places where Clang followed different paths, omitted
critical entries, and worst of all (in terms of challenges to debugging)
got the entries in a subtly wrong order.

If this breaks Clang on a distro you use, please let me know, and I'll
work with you to figure out what is needed to work on that distro. I've
checked the behavior of the latest release of Ubuntu, OpenSUSE, Fedora,
and Gentoo. I'll be testing it on those as well as Debian stable and
unstable and ArchLinux. I may even dig out a Slackware install.

No real regression tests yet, those will follow once I add enough
support for sysroot to simulate various distro layouts in the testsuite.

llvm-svn: 140981
2011-10-03 05:28:29 +00:00
Chandler Carruth 59d9ebb103 As I suspected, completely non-multilib machines just get no suffix.
Make the suffixes optional everywhere, and just make sure they have the
right value. The suffixes aren't the interesting part of this test
anyways.

Sorry for the churn as I let the bots try out various patterns.

llvm-svn: 140927
2011-10-01 02:39:57 +00:00
Chandler Carruth c5ab7efea3 Teach this test to cope with Windows suffixes so that msys builds can
run it.

llvm-svn: 140925
2011-10-01 02:08:56 +00:00
Chandler Carruth 97bb841545 Correct my failure at writing proper regex's for FileCheck. Thanks Nick.
llvm-svn: 140920
2011-10-01 01:46:47 +00:00
Chandler Carruth 91052b6851 Allow for both 'lib' and 'lib32', as both seem to be in evidence. I've
left a FIXME to go track down more distros and see if 'lib' is ever the
64-bit half.

This should hopefully appease the build bots.

llvm-svn: 140915
2011-10-01 01:26:40 +00:00
Chandler Carruth 6276a75731 There might be an 'ld' without any path prefix.
llvm-svn: 140913
2011-10-01 01:03:45 +00:00
Chandler Carruth 94bcd38d10 Add a test that ensures we get the basic multilib '-L' flags to 'ld'
invocations on Linux.

llvm-svn: 140909
2011-10-01 00:37:39 +00:00