[8u] 8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc)
Severin Gehwolf
sgehwolf at redhat.com
Mon Jun 24 15:21:00 UTC 2019
On Mon, 2019-06-24 at 16:52 +0200, Florian Weimer wrote:
> * Andrew John Hughes:
>
> > On 24/06/2019 14:54, Florian Weimer wrote:
> > > * Severin Gehwolf:
> > >
> > > > Could I please get reviews for this 8u only change? The JDK 8u build
> > > > logic for launcher files includes linker version script files (a.k.a
> > > > mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
> > > > as local. When the symbol is not visible to the dynamic loader, glibc
> > > > will use a legacy stdio implementation instead. This is a historic, x86
> > > > (32bit) only glibc issue, I've been told.
> > >
> > > It may impact other historic GNU/Linux targets, but I don't think they
> > > have OpenJDK ports. POWER and Z are 64-bit only, I assume.
> > >
> > > Thanks,
> > > Florian
> > >
> >
> > OpenJDK is built on s390 (31-bit) and ppc (32-bit) for RHEL 7.
>
> Oh. I did not know this.
>
> I looked at a recent internal s390 build, and found this:
>
> Symbol table [ 6] '.dynsym' contains 8 entries:
> 1 local symbol String table: [ 7] '.dynstr'
> Num: Value Size Type Bind Vis Ndx Name
> 0: 00000000 0 NOTYPE LOCAL DEFAULT UNDEF
> 1: 00000000 0 NOTYPE WEAK DEFAULT UNDEF _ITM_deregisterTMCloneTable
> 2: 00000000 0 NOTYPE WEAK DEFAULT UNDEF __gmon_start__
> 3: 00000000 0 NOTYPE WEAK DEFAULT UNDEF _Jv_RegisterClasses
> 4: 00000000 0 NOTYPE WEAK DEFAULT UNDEF _ITM_registerTMCloneTable
> 5: 00400474 0 FUNC GLOBAL DEFAULT UNDEF __libc_start_main at GLIBC_2.0 (2)
> 6: 00400494 0 FUNC GLOBAL DEFAULT UNDEF JLI_Launch at SUNWprivate_1.1 (3)
> 7: 004007b8 4 OBJECT GLOBAL DEFAULT 16 _IO_stdin_used
>
> Same for a ppc build:
>
> Symbol table [ 6] '.dynsym' contains 8 entries:
> 1 local symbol String table: [ 7] '.dynstr'
> Num: Value Size Type Bind Vis Ndx Name
> 0: 00000000 0 NOTYPE LOCAL DEFAULT UNDEF
> 1: 00000000 0 NOTYPE WEAK DEFAULT UNDEF _ITM_deregisterTMCloneTable
> 2: 00000000 0 NOTYPE WEAK DEFAULT UNDEF __gmon_start__
> 3: 00000000 0 FUNC GLOBAL DEFAULT UNDEF __libc_start_main at GLIBC_2.0 (2)
> 4: 00000000 0 FUNC GLOBAL DEFAULT UNDEF JLI_Launch at SUNWprivate_1.1 (3)
> 5: 00000000 0 NOTYPE WEAK DEFAULT UNDEF _Jv_RegisterClasses
> 6: 00000000 0 NOTYPE WEAK DEFAULT UNDEF _ITM_registerTMCloneTable
> 7: 100007ac 4 OBJECT GLOBAL DEFAULT 15 _IO_stdin_used
>
> Any binary which references __libc_start_main at GLIBC_2.0 and which does
> not export _IO_stdin_used in .dynsym (.symtab does not count) has this
> issue, irrespective of the architecture. The key point is support for
> the glibc 2.0 ABI level (as indicated by the GLIBC_2.0 symbol version).
> Architectures which joined in glibc 2.1 or later do not have this
> fallback code (although the _IO_stdin_used marker symbol is sometimes
> still there, quite unnecessarily).
>
> So these two builds one does not have the issue. The build is from May,
> so it can't have Severin's fix yet
> (java-1.8.0-openjdk-1.8.0.222.b04-1.el7, in case you wonder), and the
> i686 build does show the issue.
This makes sense to me. ppc 32bit and s390 31bit builds are Zero. So is
the arm 32 Fedora build for JDK 8. When we look at the linker commands
for the java executable we see:
Zero (arm32):
Linking executable java
/usr/bin/gcc -Wl,-z,relro -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Xlinker --hash-style=both -Xlinker -z -Xlinker defs -Xlinker -z -Xlinker noexecstack -Xlinker -O1 -Xlinker --allow-shlib-undefined -Xlinker -rpath -Xlinker \$ORIGIN/../lib/arm/jli -Xlinker -rpath -Xlinker \$ORIGIN/../lib/arm -lpthread -Xlinker -soname=lib.so -o /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.arm/openjdk/build/jdk8.build/jdk/objs/java_objs/java /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.arm/openjdk/build/jdk8.build/jdk/objs/java_objs/main.o -lz -L/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.arm/openjdk/build/jdk8.build/jdk/lib/arm/jli -ljli -ldl -lc
x86 from the same build:
Linking executable java
/usr/bin/gcc -Wl,-z,relro -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Xlinker --hash-style=both -Xlinker -z -Xlinker defs -Xlinker -z -Xlinker noexecstack -Xlinker -O1 -Xlinker --allow-shlib-undefined -Xlinker -rpath -Xlinker \$ORIGIN/../lib/i386/jli -Xlinker -rpath -Xlinker \$ORIGIN/../lib/i386 -lpthread -Xlinker -soname=lib.so -Xlinker -version-script=/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.i386/openjdk/jdk/make/mapfiles/launchers/mapfile-x86 -o /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.i386/openjdk/build/jdk8.build/jdk/objs/java_objs/java /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.i386/openjdk/build/jdk8.build/jdk/objs/java_objs/main.o -lz -L/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.i386/openjdk/build/jdk8.build/jdk/lib/i386/jli -ljli -ldl -lc
So the x86-32 build uses '-Xlinker -version-script ...' while the Zero
build does not. The version script (or mapfile) screws this up.
Thanks,
Severin
More information about the jdk8u-dev
mailing list