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

[Magnus Ihse Bursie]

On 2020-09-29 13:17, Kim Barrett wrote:
>> On Sep 29, 2020, at 6:51 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>
>>> On Sep 28, 2020, at 11:13 AM, Eric Liu <eric.c.liu at arm.com> wrote:
>>>
>>> Hi,
>>>
>>> Thanks for looking at this.
>>>
>>> For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work).
>>> I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy'
>>> to replace 'strncpy'.
>>>
>>>
>>> Thanks,
>>> Eric
>> […]
>> 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)
>>
>> […]
>>
>> 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}.
>>
>> Scattering pragmas for disabling -Wstringop-truncation doesn't cut it.
> Another option might be to solve https://bugs.openjdk.java.net/browse/JDK-8232187
>
Will that really help? If a os::strncpy_s method is added to hotspot, 
how should NetworkInterface.c in libnet be able to use it?

/Magnus