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

[Andrew John Hughes]

On 24/06/2019 15:52, 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.
> 
> Thanks,
> Florian
> 

Ah good, sounds like it is just an x86-32 issue then.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew