bcm5719-llvm/compiler-rt/lib/asan, branch meklort-10.0.1Project Ortega BCM5719 LLVMhttps://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.12019-11-04T19:55:51+00:00Remove unused variables, as suggested by @mcgov.2019-11-04T19:55:51+00:00Alexandre Ganeaalexandre.ganea@ubisoft.com2019-11-04T19:55:51+00:00urn:sha1:efad56b2be9b9f7d5b62d1f06541192fa6b537ee
Fixes warning: unused variable 'XXX' [-Wunused-const-variable]
[asan] Fix lint failure in asan_interface.h2019-10-31T20:58:55+00:00Evgenii Stepanoveugenis@google.com2019-10-31T20:58:55+00:00urn:sha1:cd751bcd5206b9fb3d9a46802294ffcbfb80661f[asan] Provide an interface to update an allocation stack trace.2019-10-31T20:54:46+00:00Evgenii Stepanoveugenis@google.com2019-10-19T00:17:48+00:00urn:sha1:13e04607f75bdf0e4de08b6f240501c15e8891f1
Summary:
Sometimes an allocation stack trace is not very informative. Provide a
way to replace it with a stack trace of the user's choice.
Reviewers: pcc, kcc
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69208
[sanitizer_common] Create max_allocation_size_mb flag.2019-10-30T18:26:05+00:00Matt Morehousemascasa@google.com2019-10-30T18:17:56+00:00urn:sha1:7904bd9409b86afbec763d0d95cb75ccef559379
Summary:
The flag allows the user to specify a maximum allocation size that the
sanitizers will honor. Any larger allocations will return nullptr or
crash depending on allocator_may_return_null.
Reviewers: kcc, eugenis
Reviewed By: kcc, eugenis
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69576
Reland "[ASan] Do not misrepresent high value address dereferences as null dereferences"2019-10-10T17:19:58+00:00Julian Lettnerjlettner@apple.com2019-10-10T17:19:58+00:00urn:sha1:99c9d7bd6369a7505b86d7ea75a573265436e34a
Updated: Removed offending TODO comment.
Dereferences with addresses above the 48-bit hardware addressable range
produce "invalid instruction" (instead of "invalid access") hardware
exceptions (there is no hardware address decoding logic for those bits),
and the address provided by this exception is the address of the
instruction (not the faulting address). The kernel maps the "invalid
instruction" to SEGV, but fails to provide the real fault address.
Because of this ASan lies and says that those cases are null
dereferences. This downgrades the severity of a found bug in terms of
security. In the ASan signal handler, we can not provide the real
faulting address, but at least we can try not to lie.
rdar://50366151
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D68676
> llvm-svn: 374265
llvm-svn: 374384
Revert "[ASan] Do not misrepresent high value address dereferences as null dereferences"2019-10-10T10:56:52+00:00Russell Galloprussell.gallop@gmail.com2019-10-10T10:56:52+00:00urn:sha1:c48e0873af43eb245cdcca7b9822d2ff8646231c
As it was breaking bots running sanitizer lint check
This reverts r374265 (git b577efe4567f1f6a711ad36e1d17280dd1c4f009)
llvm-svn: 374308
[ASan] Do not misrepresent high value address dereferences as null dereferences2019-10-10T00:33:04+00:00Julian Lettnerjlettner@apple.com2019-10-10T00:33:04+00:00urn:sha1:b577efe4567f1f6a711ad36e1d17280dd1c4f009
Dereferences with addresses above the 48-bit hardware addressable range
produce "invalid instruction" (instead of "invalid access") hardware
exceptions (there is no hardware address decoding logic for those bits),
and the address provided by this exception is the address of the
instruction (not the faulting address). The kernel maps the "invalid
instruction" to SEGV, but fails to provide the real fault address.
Because of this ASan lies and says that those cases are null
dereferences. This downgrades the severity of a found bug in terms of
security. In the ASan signal handler, we can not provide the real
faulting address, but at least we can try not to lie.
rdar://50366151
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D68676
llvm-svn: 374265
[compiler-rt] Use GetNextInstructionPc in signal handlers2019-10-02T21:20:37+00:00Vitaly Bukavitalybuka@google.com2019-10-02T21:20:37+00:00urn:sha1:d39e7e2cf156f5f444637fb3d26e98d33b1bfc19
Summary:
All other stack trace callers assume that PC contains return address.
HWAsan already use GetNextInstructionPc in similar code.
PR43339
Reviewers: eugenis, kcc, jfb
Subscribers: dexonsmith, dberris, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D68313
llvm-svn: 373529
[compiler-rt] Fix lint check failure on comments2019-09-22T15:31:03+00:00Jinsong Jijji@us.ibm.com2019-09-22T15:31:03+00:00urn:sha1:e2af0e5ee830693fee0ddf609885508df1e06f45
This fixes buildbot failures for https://reviews.llvm.org/rL372459.
(at least on PowerPC/Z )
The fix is generated by running clang-format on the error lines only.
llvm-svn: 372511
Add __lsan::ScopedInterceptorDisabler for strerror(3)2019-09-21T07:45:02+00:00Kamil Rytarowskin54@gmx.com2019-09-21T07:45:02+00:00urn:sha1:1b58389428ed07a7322ba9c2bcaeec99807f9457
Summary:
strerror(3) on NetBSD uses internally TSD with a destructor that is never
fired for exit(3). It's correctly called for pthread_exit(3) scenarios.
This is a case when a leak on exit(3) is expected, unavoidable and harmless.
Reviewers: joerg, vitalybuka, dvyukov, mgorny
Reviewed By: vitalybuka
Subscribers: dmgreen, kristof.beyls, jfb, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67337
llvm-svn: 372461