This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] i386: Add _startup_sbrk and _startup_fatal [BZ #21913]
On Mon, Aug 7, 2017 at 4:47 AM, Zack Weinberg <firstname.lastname@example.org> wrote:
> On Sun, Aug 6, 2017 at 6:26 PM, H.J. Lu <email@example.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?
It only applies to Linux/x86 since Linux/x86-64 always use "syscall"
which doesn't need TLS nor relocation.
> 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.)
All static tests fail when GCC is default to PIE.
> 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?
To initialize TLS, we need a single syscall, sbrk. My patch provides
_startup_sbrk which can be used befor TLS is initialized.