This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] i386: Add _startup_sbrk and _startup_fatal [BZ #21913]
- From: Zack Weinberg <zackw at panix dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 7 Aug 2017 07:47:07 -0400
- Subject: Re: [PATCH] i386: Add _startup_sbrk and _startup_fatal [BZ #21913]
- Authentication-results: sourceware.org; auth=none
- References: <20170806222606.GA13700@gmail.com>
On Sun, Aug 6, 2017 at 6:26 PM, H.J. Lu <firstname.lastname@example.org> 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?