Commit Graph

5 Commits

Author SHA1 Message Date
Ed Schouten 610adaeec4 Don't enable PIE on i686-unknown-cloudabi.
We're only going to provide support for using PIE on architectures that
provide PC-relative addressing. i686 is not one of those, so add the
necessary bits for only passing in -pie -zrelro conditionally.

llvm-svn: 278395
2016-08-11 20:03:22 +00:00
Ed Schouten 506f295a10 Enable PIE for CloudABI.
As we're currently working on making CloudABI executables easier to
emulate in userspace (e.g., on OS X and Windows), it makes a whole lot
of sense to build these using PIE. By using PIE, they can simply be
loaded into the existing process address space without clashes.

PIE support got added to CloudABI's C library and seems to work pretty
well. CloudABI does not make use of an ld.so, so the binary's _start()
has all the logic in it to do the relocations.

Now that all but one bug in LLD relating to PIE support have been
squashed (and a patch for that is already in code review), I'd like to
go ahead and force the use of PIE for Clang 3.9. When released, we'll
also switch over to using LLD exclusively.

llvm-svn: 265546
2016-04-06 15:37:06 +00:00
Ed Schouten fc79d2ca42 Enable the SafeStack sanitizer on CloudABI by default.
Over the last month we've been testing SafeStack extensively. As far as
we know, it works perfectly fine. That why I'd like to see us having
this enabled by default for CloudABI.

This change introduces a getDefaultSanitizers() function that toolchains
can use to specify which sanitizers are enabled by default. Once all
flags are processed, only flags that had no -fno-sanitize overrides are
enabled.

Extend the thests for CloudABI to test both the default case and the
case in which we want to explicitly disable SafeStack.

Reviewed by:	eugenis, pcc
Differential Revision:	http://reviews.llvm.org/D18505

llvm-svn: 264787
2016-03-29 21:13:53 +00:00
Ed Schouten 6e57615ac8 Enable -ffunction-sections and -fdata-sections for CloudABI by default.
Unlike most of the other platforms supported by Clang, CloudABI only
supports static linkage, for the reason that global filesystem access is
prohibited. Functions provided by dlfcn.h are not present. As we know
that applications will not try to do any symbol lookups at run-time, we
can garbage collect unused code quite aggressively. Because of this, it
makes sense to enable -ffunction-sections and -fdata-sections by
default.

Object files will be a bit larger than usual, but the resulting binary
will not be affected, as the sections are merged again. However, when
--gc-sections is used, the linker is able to remove unused code far more
more aggressively. It also has the advantage that transitive library
dependencies only need to be provided to the linker in case that
functionality is actually used.

Differential Revision:	http://reviews.llvm.org/D8635
Reviewed by:	echristo

llvm-svn: 233299
2015-03-26 17:50:28 +00:00
Ed Schouten 3c3e58c42d Let Clang invoke CloudABI's linker.
Now that CloudABI's target information and header search logic for Clang
has been submitted, the only thing that remains to be done is adding
support for CloudABI's linker.

CloudABI uses Binutils ld, although there is some work to use lld
instead. This means that this code is largely based on what we use on
FreeBSD. There are some exceptions, however:

- Only static linking is performed. CloudABI does not support any
  dynamically linked executables.
- CloudABI uses compiler-rt, libc++ and libc++abi unconditionally. Link
  in these libraries instead of using libgcc_s, libstdc++, etc.
- We must ensure that the .eh_frame_hdr is present to make C++
  exceptions work properly.


Differential Revision:	http://reviews.llvm.org/D8250

llvm-svn: 233269
2015-03-26 11:13:44 +00:00