Commit Graph

4 Commits

Author SHA1 Message Date
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Rainer Orth 1a9b072338 [Sanitizers] Solaris largefile fixes
While testing the Solaris libsanitizer port on GCC mainline, I found that
I'd messed up
the largefile checks in various ways, some of which showed as compile failures
(wrong structure sizes and member offsets), others at runtime, some of those only
on sparc as a big-endian target.

This patch fixes all of them:

- OFF_T is now correctly defined for 32-bit largefile and traditional
  environments, and 64-bit.

- The definition of __sanitizer_dirent now checks the correct conditionals.

- sanitizer_procmaps_solaris.cc undefines _FILE_OFFSET_BITS: before
  Solaris 11.4 <procfs.h> doesn't even compile with largefile support
  enabled, but the use at hand doesn't need it anyway while g++ 9 will
  define _FILE_OFFSET_BITS=64 out of the box.

- With full largefile support enabled, one needs to use e.g. mmap64
  instead of mmap; this is hidden behind macros.

With this patch I could bootstrap gcc mainline on both sparc-sun-solaris2.11 and
i386-pc-solaris2.11.  In addition, I've successfully built llvm on
i386-pc-solaris2.11.

Differential Revision: https://reviews.llvm.org/D54101

llvm-svn: 346153
2018-11-05 19:19:15 +00:00
Kamil Rytarowski d6b30fffda Correct the setitimer interceptor on NetBSD
Summary:
itimerval can contain padding that may be legitimately uninitialized.

On NetBSD there are four integers of type "long, int, long, int", the
int argument stands for __sanitizer_suseconds_t. Compiler adds extra
padding in this layout.

Check every field of struct itimerval separately.

Define __sanitizer_suseconds_t as long on FreeBSD, Linux and SmartOS,
and int on NetBSD. Define __sanitizer_timeval and __sanitizer_itimerval.

Sponsored by <The NetBSD Foundation>

Reviewers: eugenis, joerg, vitalybuka

Reviewed By: vitalybuka

Subscribers: emaste, kubamracek, llvm-commits, #sanitizers

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D41502

llvm-svn: 322399
2018-01-12 20:45:56 +00:00
Kamil Rytarowski 271018d216 [Sanitizers] Basic sanitizer Solaris support (PR 33274)
Summary:
This is the first mostly working version of the Sanitizer port to 32-bit Solaris/x86.
It is currently based on Solaris 11.4 Beta.

This part was initially developed inside libsanitizer in the GCC tree and should apply to
both.  Subsequent parts will address changes to clang, the compiler-rt build system
and testsuite.

I'm not yet sure what the right patch granularity is: if it's profitable to split the patch
up, I'd like to get guidance on how to do so.

Most of the changes are probably straightforward with a few exceptions:

* The Solaris syscall interface isn't stable, undocumented and can change within an
  OS release.  The stable interface is the libc interface, which I'm using here, if possible
  using the internal _-prefixed names.

* While the patch primarily target 32-bit x86, I've left a few sparc changes in.  They
  cannot currently be used with clang due to a backend limitation, but have worked
  fine inside the gcc tree.

* Some functions (e.g. largefile versions of functions like open64) only exist in 32-bit
  Solaris, so I've introduced a separate SANITIZER_SOLARIS32 to check for that.

The patch (with the subsequent ones to be submitted shortly) was tested
on i386-pc-solaris2.11.  Only a few failures remain, some of them analyzed, some
still TBD:

    AddressSanitizer-i386-sunos :: TestCases/Posix/concurrent_overflow.cc
    AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc
    AddressSanitizer-i386-sunos :: TestCases/log-path_test.cc
    AddressSanitizer-i386-sunos :: TestCases/malloc-no-intercept.c
    AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/concurrent_overflow.cc
    AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/start-deactivated.cc
    AddressSanitizer-i386-sunos-dynamic :: TestCases/default_options.cc
    AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc
    AddressSanitizer-i386-sunos-dynamic :: TestCases/log-path_test.cc
    AddressSanitizer-i386-sunos-dynamic :: TestCases/malloc-no-intercept.c

   SanitizerCommon-Unit :: ./Sanitizer-i386-Test/MemoryMappingLayout.DumpListOfModules
    SanitizerCommon-Unit :: ./Sanitizer-i386-Test/SanitizerCommon.PthreadDestructorIterations

Maybe this is good enough the get the ball rolling.

Reviewers: kcc, alekseyshl

Reviewed By: alekseyshl

Subscribers: srhines, jyknight, kubamracek, krytarowski, fedor.sergeev, llvm-commits, #sanitizers

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D40898

llvm-svn: 320740
2017-12-14 20:14:29 +00:00