Re: [PATCH] i386: Add _startup_sbrk and _startup_fatal [BZ #21913]

[Zack Weinberg <zackw at panix dot com>]

On Sun, Aug 6, 2017 at 6:26 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Linux/x86, there are 3 ways to make a system call:
>
> 1. call *%gs:SYSINFO_OFFSET.  This requires TLS initialization.
> 2. call *_dl_sysinfo.  This requires relocation of _dl_sysinfo.
> 3. int $0x80.  This works everywhere.
>
> When an object file is compiled with PIC, #1 is prefered since it is
> faster than #3 and doesn't require relocation of _dl_sysinfo.  For
> dynamic executables, ld.so initializes TLS.  However, for static
> executables, before TLS is initialized by __libc_setup_tls, #3 should
> be used for syscalls.  This patch adds _startup_sbrk and _startup_fatal
> to be used in static executables before __libc_setup_tls is called.  By
> default, they are defined to __sbrk and __libc_fatal, respectively.  On
> x86, a special _startup_sbrk is provided and _startup_fatal is turned
> into ABORT_INSTRUCTION.
>
> Any comments?

I have questions:

1) When you say "Linux/x86", do you mean specifically the old 32-bit
ABI, or does this apply to x32 and/or x64 as well?
2) This is described as fixing a bug; please add a test case. (The bug
report describes a crash during 'make install', but that's not good
enough, it should be caught by 'make check' pre-installation.)
3) Couldn't we avoid adding complexity in shared code by doing startup
in a slightly different order?  Specifically, why can't we ensure that
TLS is initialized, at least enough of it that "call
*%gs:SYSINFO_OFFSET" works, before we attempt to make any syscalls?

zw