[RFR] [8u] 8u201 Upstream Sync
Andrew Hughes
gnu.andrew at redhat.com
Tue Feb 26 21:38:51 UTC 2019
On Tue, 26 Feb 2019 at 11:53, Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 2/26/19 3:00 AM, Andrew Hughes wrote:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u201.upstream/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u201.upstream/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u201.upstream/jaxws/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u201.upstream/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u201.upstream/nashorn/merge.changeset
>
> These look trivially correct.
>
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u201.upstream/jdk/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u201.upstream/hotspot/merge.changeset
>
> These are test only changes. Look good.
>
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u201.upstream/root/merge.changeset
>
> This includes some changes that add -fstack-protector.
>
Yeah, thanks for raising that. I'd forgotten it with it not being on
the list of bugs.
We backported this already in our 8u201. We were never supplied the 8u
version, so
I based this on the 11u version:
https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/8b060cdf0251
to give
https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/37970a1c26dd
and
https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/931719aa2469
I still think that's the right backport. The 8u upstream version is
different in that it does
everything in the autoconf code. It also only does it for x86 & x86_64
for some reason
(not the case on 11u)
On x86_64, I'm now seeing three -fstack-protector invocations per JDK
compilation:
e.g.
[8] CFLAGS := -Wall -Wno-parentheses -Wextra -Wno-unused
-Wno-unused-parameter -Wformat=2 -pipe -fstack-protector -D_GNU_SOURC\
E -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer
-fstack-protector -D_LP64=1 -D_LITTLE_ENDIAN -DLINUX -DARCH='"amd6\
4"' -Damd64 -DNDEBUG -DRELEASE='"1.8.0-internal"'
-I/home/andrew/builder/shenandoah8/jdk/include
-I/home/andrew/builder/shenand\
oah8/jdk/include/linux
-I/home/andrew/projects/openjdk/upstream/shenandoah.8/jdk/src/share/javavm/export
-I/home/andrew/project\
s/openjdk/upstream/shenandoah.8/jdk/src/solaris/javavm/export
-I/home/andrew/projects/openjdk/upstream/shenandoah.8/jdk/src/sha\
re/native/common
-I/home/andrew/projects/openjdk/upstream/shenandoah.8/jdk/src/solaris/native/common
-O2 -pipe -march=core2 -gg\
db -mno-tls-direct-seg-refs -fno-strict-aliasing -fstack-protector
-fno-delete-null-pointer-checks -fno-lifetime-dse -fPIC -I/h\
ome/andrew/builder/shenandoah8/jdk/gensrc_headers
-I/home/andrew/projects/openjdk/upstream/shenandoah.8/jdk/src/share/native/su\
n/security/smartcardio
-I/home/andrew/projects/openjdk/upstream/shenandoah.8/jdk/src/solaris/native/sun/security/smartcardio
-I\
/home/andrew/projects/openjdk/upstream/shenandoah.8/jdk/src/solaris/native/sun/security/smartcardio/MUSCLE
The one I added is after '-pipe'. The upstream patch adds them after both after
-fno-omit-frame-pointer and -fno-strict-aliasing because it seems both
CCXXFLAGS_JDK and CFLAGS_JDK are used, whereas the change seems to
expect one or the other.
Should we drop the changes from upstream? Should we push our version upstream
so it matches 11u?
I'm not sure why this was pushed as a security fix (and thus with no
public discussion).
Many distros already use this flag when building anyway.
> Thumbs up.
>
> -Aleksey
>
>
>
--
Andrew :)
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
More information about the shenandoah-dev
mailing list