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

[Florian Weimer]

* 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.

Thanks,
Florian