Mon, Mar 30
Tue, Mar 24
lgtm with comment and nits
The discussion and the tests should distinguish the COMDAT semantics from the --gc-sections semantics. They are related but distinct.
Mon, Mar 23
Sat, Mar 21
Fri, Mar 20
I think if you provide symbols for the section bounds, they should be __start_note_gnu_build_id and __stop_note_gnu_build_id. But that doesn't seem enough of an improvement over parsing phdrs from __ehdr_start to merit the feature IMHO. Consumers still have to parse (or worse yet, assume) the note headers. What would make things trivial for consumers is a pair of symbols giving exactly the bounds of the *payload*, i.e. just the build ID itself (and presenting its variable size in a simple manner).
Thu, Mar 19
A comment wouldn't hurt.
Tue, Mar 10
I wholeheartedly endorse documenting the policy on linker script semantics. I think the described deviation from GNU semantics for cases where explicit output section alignment doesn't jibe with input section alignment is generally fine. That is, I think this corner case is best avoided and I'm not too concerned with exactly how it goes when it happens. The warning for the case of an explicit address that is misaligned wrt input section sh_addralign is the most important thing for avoiding accidents. For the explicit alignment being less than than input requirements, the lld behavior of using the maximum of the two seems sensible to me (essentially the explicit alignment in the linker script is just another of the requirements like all the inputs' sh_addralign values and you align to the maximum of the whole set, which is perfectly intuitive). If anything, I think the GNU linkers should warn about violating input sh_addralign requirements if they're going to have that behavior.
Feb 21 2020
Thanks! Can you land it for me?
Thanks! Can you land it for me?
Jan 30 2020
Jan 28 2020
Fixed patch rebasing snafu that dropped LsanOnDeadlySignal code from lsan_posix.cpp.
Reverted after landing due to patch rebasing snafu that dropped the LsanOnDeadlySignal function.
Jan 27 2020
There should be test coverage that verifies the visibility gets set, but lgtm with that.
Moved ReportIfNotSuspended out of #if.
Jan 25 2020
Jan 24 2020
Fixed Android SafeStack case, now passing check-clang.
I've made the style changes you asked for and clang-format'd the files I touched. But note that all of these changes are to existing code that I just moved and left exactly as it had been and not anything I'd added. I erred on the side of leaving things alone rather than cleaning them up. I've now done the opposite as you asked, though it's not entirely consistent with the style and formatting of the existing code in the same directory. I'm happy to use whatever style choices you prefer, but it's easiest to do that when the codebase is consistent with those choices already.
Style changes to copied code, clang-format.
Jan 23 2020
I think I've done everything Vitaly's last review asked for. Thanks.
Split out ThreadContext refactoring into a separate patch.
Updated related changes following review comments.
Jan 18 2020
I've split part of the patch out and done a substantial refactoring of the standalone lsan thread stuff following Vitaly's review.
Generic refactoring patch split out.
Standalone LSan port refactored following review comments.
Rebased, added a comment.
Jan 16 2020
Dec 17 2019
Oct 16 2019
It's time to land this now. Can one of you commit it for me?
Aug 24 2019
This should land only after we've done our first stages of downstream roll-out and burn-in testing. But setting it up now.
Aug 15 2019
Aug 14 2019
Aug 4 2019
Jul 17 2019
Jul 11 2019
Jul 3 2019
AFAICT the inlining is the whole point of FastPoisonShadow so this LGTM as is.
Jun 29 2019
Jun 24 2019
Move logic out of RawCoverage constructor.
Jun 23 2019
https://fuchsia-review.googlesource.com/c/fuchsia/+/295508 has the runtime implementation that motivated this.
May 31 2019
May 30 2019
May 28 2019
May 27 2019
May 24 2019
lgtm contingent on verifying intended behavior changes and adding comments. The factoring suggestion for the triple,triple searching is preferred but at your discretion, though I'd really like to see at least comments.
May 21 2019
lgtm with one nit: either change to an assert or improve the comment to clarify what other cases are expected
May 14 2019
May 6 2019
Previously the same local symbol name was being used for both things in an uncoordinated fashion. The logic in places like ValueSymbolTable::createValueName leads to the second one getting renamed with some ".digits" suffix to make them unique.
Then the code that emits the references between the init_array and the actual function and sets the COMDAT group name assumed it could use the original name throughout, but in some places this was replaced with the suffixed name and in some places it was not, leading to the incorrect references.
Sorting R_*_RELATIVE relocs first and setting REL(A)COUNT is a format requirement, period. It's not a debatable question of optimization.
May 5 2019
May 4 2019
This works for my case that led to me to file https://bugs.llvm.org/show_bug.cgi?id=41693 as a linker issue.
May 3 2019
The sorting behavior is entirely an optimization for locality at dynamic reloc time. Both locality of symtab indices and locality of reloc offsets are useful to that goal.
Apr 30 2019
Apr 24 2019
Apr 3 2019
IMHO the library code should use #if !__has_feature(...) to avoid the definitions entirely when built with a sanitizer whose runtime provides them.
But this is a fine way to achieve that while we wait for those libraries to be fixed for sanitized builds.
Apr 2 2019
Mar 28 2019
Feb 16 2019
This is only on GCC trunk (i.e. 9), not in 8.2 or even the current gcc-8 branch. So clarify the log entry. We don't know if 8.x,x>2 will add it or only gcc 9.
Feb 14 2019
Feb 13 2019
I only really looked at the Fuchsia code.
Feb 9 2019
lgtm with a comment (and perhaps an assertion).