8227652: SetupOperatorNewDeleteCheck should discuss deleting destructors
Please review this explanatory comment being added to the description of the check for using global operator new/delete in Hotspot code. The described situation is somewhat obscure, and encountering it for the first time (or again after a long time, as happened to me recently) can be quite puzzling. CR: https://bugs.openjdk.java.net/browse/JDK-8227652 Webrev: http://cr.openjdk.java.net/~kbarrett/8227652/open.00/
Re: [Ping?] RFR: 8227397: Add --with-extra-asflags configure option
In CompileJvm.gmk, I'd replace
-ASFLAGS := $(JVM_ASFLAGS), \
+ASFLAGS := $(JVM_ASFLAGS) $(EXTRA_ASFLAGS), \
with adding EXTRA_ASFLAGS to JVM_ASFLAGS right after where JVM_LDFLAGS is
finalized, vis
JVM_LDFLAGS += \
$(SHARED_LIBRARY_FLAGS) \
$(JVM_LDFLAGS_FEATURES) \
$(EXTRA_LDFLAGS) \
#
+
+ JVM_ASFLAGS += ${EXTRA_ASFLAGS)
That way, uses of EXTRA_xxFLAGS are all in one place and possible future
file-specific assembler flags don't have to duplicate adding EXTRA_ASFLAGS.
Otherwise, good.
Paul
On 7/15/19, 7:27 AM, "build-dev on behalf of Severin Gehwolf"
wrote:
Anyone?
On Mon, 2019-07-08 at 17:56 +0200, Severin Gehwolf wrote:
> Hi,
>
> Could I please get a review for this patch which adds a new configure
> option --with-extra-asflags? The issue at hand is that we, Red Hat,
> need to pass certain extra flags to the assembler when OpenJDK is being
> compiled. -Wa,--generate-missing-build-notes=yes in our case. That's
> currently not possible and extra C/C++ flags would need to be used,
> which seems not nice.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227397
> webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227397/01/webrev/
>
> After this patch extra assembler flags get added to *.s/.S files for
> libjvm.so:
>
> $ grep -n generate-missing-build-notes=yes
build/linux-x86_64-server-release/build.log
> 1049: [18] ASFLAGS := -m64 -Wa,--generate-missing-build-notes=yes
> 15005:( /usr/bin/rm -f
/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o.log
&& /usr/bin/gcc -c -m64 -Wa,--generate-missing-build-notes=yes -g -o
/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o
/disk/openjdk/upstream-sources/openjdk-head/src/hotspot/os_cpu/linux_x86/linux_x86_64.s
> >(/usr/bin/tee -a
/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o.log)
2> >(/usr/bin/tee -a
/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o.log
>&2) || ( exitcode=$? && /usr/bin/cp
/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o.log
/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_linux_x86_64.o.log
&& /usr/bin/cp
/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o.cmdline
/disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_linux_x86_64.o.cmdline
&& exit $exitcode ) )
>
> I'll run this through jdk/submit before I push.
>
> Thoughts?
>
> Thanks,
> Severin
Re: JLI_Launch has mangled name in jli.dll when building for win32
Thanks for pointing me into the right direction. So it looks as if this kind of mangling is to be expected on win32, which is also shown by the fact that multiple JDK-builds for win32, eg AdoptOpenJDK or Liberica JDK have their jli.dll that way. But that in turn means that jpackage should be prepared to handle this situation. To that end I've created https://bugs.openjdk.java.net/browse/JDK-8227684 together with a patch that would fix jpackage for win32. Am 11.07.19 um 16:06 schrieb Thomas Stüfe: > Hi Robert, > > This means that the function is using the __stdcall calling > convention. I do not know whether this is correct or not, but caller > and callee have to agree on the calling convention used, so the > prototype for that function used when compiling the caller code must > have been declared with __stdcall too for this to work. > > This is a 32bit Windows specialty. No other platform, including 64 bit > Windows, has different calling conventions. > > Hope that helps, > > Cheers, Thomas > > > On Thu, Jul 11, 2019, 09:34 Robert Lichtenberger > mailto:r.lichtenber...@synedra.com>> wrote: > > I have tried to use the jpackage EA version in combination with the > win32-build of Java 12 from AdoptOpenJDK. > I was able to build the jpackage EA from the sandbox and built an > image > from the win32 Java 12 build, which then was successfully combined > using > jpackage's --runtime-image option. (BTW I was able to produce working > packages for win64, mac and linux in that way). > > Now when I tried to start the win32 package I get an error message: > Failed to locate JLI_Launch. > > I digged into the jpackage/launcher code and found out that > runtime/bin/jli.dll is loaded and the function JLI_Launch is called. > > But the jli.dll in the win32-build of Java 12 from AdoptOpenJDK has a > name mangled version of JLI_Launch in it (_JLI_Launch@56) which > is (I > think) the reason that the JVM cannot be started. > > I've since tried to build Java 12 myself and the effect is > reproducible. > When I build for win64, the jli.dll is correct, when I build > --with-target-bits=32 from the exact same sources the jli.dll has the > mangled name. > > Other pre-built JDKs (e.g. Liberica JDK) have the same "problem". > > Any ideas/hints as to what could cause the problem would be most > welcome > :-). > >
Re: [Ping?] RFR: 8227397: Add --with-extra-asflags configure option
Anyone? On Mon, 2019-07-08 at 17:56 +0200, Severin Gehwolf wrote: > Hi, > > Could I please get a review for this patch which adds a new configure > option --with-extra-asflags? The issue at hand is that we, Red Hat, > need to pass certain extra flags to the assembler when OpenJDK is being > compiled. -Wa,--generate-missing-build-notes=yes in our case. That's > currently not possible and extra C/C++ flags would need to be used, > which seems not nice. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227397 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8227397/01/webrev/ > > After this patch extra assembler flags get added to *.s/.S files for > libjvm.so: > > $ grep -n generate-missing-build-notes=yes > build/linux-x86_64-server-release/build.log > 1049: [18] ASFLAGS := -m64 -Wa,--generate-missing-build-notes=yes > 15005:( /usr/bin/rm -f > /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o.log > && /usr/bin/gcc -c -m64 -Wa,--generate-missing-build-notes=yes -g -o > /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o > > /disk/openjdk/upstream-sources/openjdk-head/src/hotspot/os_cpu/linux_x86/linux_x86_64.s > > >(/usr/bin/tee -a > /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o.log) > 2> >(/usr/bin/tee -a > /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o.log > >&2) || ( exitcode=$? && /usr/bin/cp > /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o.log > > /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_linux_x86_64.o.log > && /usr/bin/cp > /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/linux_x86_64.o.cmdline > > /disk/openjdk/upstream-sources/openjdk-head/build/linux-x86_64-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_linux_x86_64.o.cmdline > && exit $exitcode ) ) > > I'll run this through jdk/submit before I push. > > Thoughts? > > Thanks, > Severin
