Re: [PATCH 0/3] Libsanitizer: merge from trunk

[Jeff Law <law at redhat dot com>]

On 8/13/19 7:07 AM, Martin Liska wrote:
> Hi.
> 
> For this year, I decided to make a first merge now and the
> next (much smaller) at the end of October.
> 
> The biggest change is rename of many files from .cc to .cpp.
> 
> I bootstrapped the patch set on x86_64-linux-gnu and run
> asan/ubsan/tsan tests on x86_64, ppc64le (power8) and
> aarch64.
> 
> Libasan SONAME has been already bumped compared to GCC 9.
> 
> For other libraries, I don't see a reason for library bumping:
> 
> $ abidiff /usr/lib64/libubsan.so.1.0.0 ./x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs/libubsan.so.1.0.0 --stat
> Functions changes summary: 0 Removed, 0 Changed, 4 Added functions
> Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
> Function symbols changes summary: 3 Removed, 0 Added function symbols not referenced by debug info
> Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info
> 
> $ abidiff /usr/lib64/libtsan.so.0.0.0  ./x86_64-pc-linux-gnu/libsanitizer/tsan/.libs/libtsan.so.0.0.0 --stat
> Functions changes summary: 0 Removed, 0 Changed, 47 Added functions
> Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
> Function symbols changes summary: 1 Removed, 2 Added function symbols not referenced by debug info
> Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info
> 
> Ready to be installed?
ISTM that a sanitizer merge during stage1 should be able to move forward
without ACKs.  Similarly for other runtimes where we pull from some
upstream master.

I'd be slightly concerned about the function removals, but I don't think
we've really tried to be ABI stable for the sanitizer runtimes.

jeff