RFR(S): 8196992: Resolve disabled warnings for libdt_socket

[Chris Plummer]

Hello,

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8196992

diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk 
b/make/lib/Lib-jdk.jdwp.agent.gmk

--- a/make/lib/Lib-jdk.jdwp.agent.gmk
+++ b/make/lib/Lib-jdk.jdwp.agent.gmk
@@ -43,7 +43,6 @@
 OPTIMIZATION := LOW, \
 CFLAGS := $(CFLAGS_JDKLIB) -DUSE_MMAP \
 $(LIBDT_SOCKET_CPPFLAGS), \
-    DISABLED_WARNINGS_gcc := shift-negative-value, \
 MAPFILE := $(TOPDIR)/make/mapfiles/libdt_socket/mapfile-vers, \
 LDFLAGS := $(LDFLAGS_JDKLIB) \
 $(call SET_SHARED_LIBRARY_ORIGIN), \

This change is undoing the makefile change done as part of JDK-8196985. 
The only warning that was turning up in libdt_socket code before 
JDK-8196985 was done has already been fixed by JDK-8196909. Thus no 
warnings need to be fixed.


After removing the above makefile code, I tested by building with the 
new toolchain. As a first test I undid the socketTransport.cpp fix from 
JDK-8196909 to verify that the new toolchain exposed the warning. Then I 
reverted socketTransport.cpp back to tip sources and saw no warnings 
with the new toolchain.


thanks,

Chris

Re: RFR: JDK-8198569: SetupTextFileProcessing should use sed with 'g'

[Tim Bell]

Erik:


I'm currently trying to use SetupTextFileProcessing with a file where
the same replacement string appears twice on the same row. This doesn't
work. To fix it, I would like to add /g on the sed replacement expressions.

Webrev: http://cr.openjdk.java.net/~erikj/8198569/webrev.01/

Bug: https://bugs.openjdk.java.net/browse/JDK-8198569



Looks good.

/Tim

RFR: JDK-8198569: SetupTextFileProcessing should use sed with 'g'

[Erik Joelsson]

I'm currently trying to use SetupTextFileProcessing with a file where 
the same replacement string appears twice on the same row. This doesn't 
work. To fix it, I would like to add /g on the sed replacement expressions.


Webrev: http://cr.openjdk.java.net/~erikj/8198569/webrev.01/

Bug: https://bugs.openjdk.java.net/browse/JDK-8198569

/Erik

Re: RFR: JDK-8198243: Add build time check for global operator new/delete in object files

[John Rose]

On Feb 22, 2018, at 11:41 AM, Erik Joelsson  wrote:
> 
> We could grep for the mangled strings for the operators instead, which is 
> super fast. Problem is just figuring out all the possible combinations.

Idea:  Do a config-style move where you compile a test file of C++ code,
strip out all the names from the object file, and throw the rest away.

Even if we just had a hand-maintained list of strings, it might catch
bugs fast enough to make it worth chasing the bit-rot of the names.
Basically, have a black list of linker names (per OS–or not?), and
keep it updated as people notice problems.

— John

Re: RFR: JDK-8198243: Add build time check for global operator new/delete in object files

[Erik Joelsson]

On 2018-02-21 21:06, David Holmes wrote:

On 22/02/2018 4:07 AM, Erik Joelsson wrote:

Hello,


On 2018-02-20 21:33, David Holmes wrote:


a) how much time it adds to the build?

I have not done extensive testing, but on my Linux workstation with 
32 hw threads, building just hotspot release build from a clean 
workspace increased maybe 1 or 2 seconds (at around 90s total), but 
the variance was around the same amount as that.

b) why this doesn't work for Solaris Studio?

I didn't put a lot of effort into trying to figure it out. The check 
used was provided by Kim Barrett, for Linux only. I figured it would 
be simple enough to get it to work on mac and succeeded there. It 
should certainly be possible to implement a similar check on Solaris, 
but is it worth the time to do it? Both development time and 
increased build time on one of the slower build platforms?


Depends how concerned we are with detecting this problem in OS 
specific source code?


I investigated this some more. I was able to do it successfully, but the 
build time cost is way too large here. The culprit is c++filt on Solaris 
which is incredibly costly, and the gnu version does not demangle 
Solaris Studio symbols. I don't think we should do this on Solaris.


We could grep for the mangled strings for the operators instead, which 
is super fast. Problem is just figuring out all the possible combinations.


/Erik

To be honest I'm not sure this pulls its own weight regardless.

David


/Erik

Thanks,
David

On 21/02/2018 4:05 AM, Erik Joelsson wrote:

Hello,

This patch adds a build time check for uses of global operators new 
and delete in hotspot C++ code. The check is only run with 
toolchains GCC and Clang (Linux and Macos builds). I have also 
modified the Oracle devkit on Linux to add the necessary symlink so 
that objdump will get picked up by configure.


This change is depending on several fixes removing such uses that 
are currently in jdk/hs so this change will need to be pushed there 
as well.


Bug: https://bugs.openjdk.java.net/browse/JDK-8198243

Webrev: http://cr.openjdk.java.net/~erikj/8198243/webrev.01/

/Erik