On 2020-09-29 13:17, Kim Barrett wrote:
On Sep 29, 2020, at 6:51 AM, Kim Barrett <kim.barr...@oracle.com> wrote:
On Sep 28, 2020, at 11:13 AM, Eric Liu <eric.c....@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
