RFR(S): 8252407: Build failure with gcc-8+ and asan

[Eric Liu]

Hi Kim,

Thanks for your review.
I tried to solve the problem with your suggestion, and have just one question.

> On 29 September 2020 18:51 PM, Kim Barrett <kim.barrett at oracle.com> wrote:

> I don't think using memory functions in place of string functions for string
> manipulation is really an improvement.
Yes, the original code has no problem basically but as you said asan seems incompatible with
-Wstringop-truncation.  Using 'memcpy' just a workaround.

> I did a bit of experimenting.
> 
> With gcc10.2, and using the --enable-asan configure option, we get a
> -Wstringop-truncation warning in CompilerCounters::set_current_method, even
> after careful adjustment of the code to use the documented idiom for
> avoiding that warning.
> 
> I initially wondered whether this might be only in fastdebug builds, where
> we also define _FORTIFY_SOURCE=2.  The asan faq
> https://github.com/google/sanitizers/wiki/AddressSanitizer#faq
> says asan doesn't work well with _FORTIFY_SOURCE.
> 
> But the same warning occurs in a release build, where we aren't defining
> _FORTIFY_SOURCE.

> At this point all I can conclude is that --enable-asan (i.e.
> -fsanitize=address) is simply incompatible with -Wstringop-truncation, at
> least through gcc10.  That seems like a bug that someone should report.
> (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650)
> 
> We don't normally build with -fsanitize=address; that's something that
> someone might want to turn on sometimes for testing or debugging, but I
> don't think we're planning to have it always on, even in debug builds.

> Since it seems to be incompatible with various other options that we *do*
> normally use, I think the way to allow --enable-asan to be (possibly) usable
> is in the build system at configure time. That is, the --enable-asan
> configure option should, in addition to adding -fsanitize=address, also (1)
> disable -Wstringop-truncation and (2) disable the defining of
> _FORTIFY_SOURCE in fastdebug builds.  It looks like making those changes
> involves conditionalizing their addition/removal using ${ASAN_ENABLED}.

Disable -Wstringop-truncation seems more reasonable. 
Is that necessary to disable _FORTIFY_SOURCE in fastdebug? With gcc10.1, 
disable -Wstringop-truncation seems enough. 

I didn't test with fastdebug mode before, and now it has been tested in our internal
both with release and fastdebug mode.


Thanks,
Eric