[8u] 8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc)

[Severin Gehwolf]

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